TypeScript generic parameter default types and new strict compilation option

Overview

TypeScript 2.3 adds support for declaring default types for generic parameters, allowing you to specify default types for type parameters in generic types.

Next, let’s see how to migrate the following react component from js (and jsX) to TypeScript (and TSX) by using generic parameter defaults:

class Greeting extends react.Component {
  render() {
    return <span>Hello, {this.props.name}!</span>;
  }
}

Create a type definition for the component class

Let's start by creating a type definition for the Component class. Each class-based React component has two properties: props and state. The type definition structure is roughly as follows:

declare namespace React {
  class Component {
    props: any;
    state: any;
  }
}

Note that this is a greatly simplified example because we are demonstrating the contents of generic type parameters and their default values.

Now you can call the Component defined above through inheritance:

class Greeting extends React.Component {
  render() {
    return <span>Hello, {this.props.name}!</span>
  }
}

We can create an instance of the component as follows:

<Greeting name="world" />

Rendering the above component will generate the following html:

<span>Hello, World!</span>

Nice, keep going.

Defining Props and State using generic types

While the example above compiles and runs just fine, our Component type definition is not very precise. Since we set the props and state types to any, the TypeScript compiler can't help us much.

Let's be more specific and use two generic types: Props and State, so that we can accurately describe the structure of props and state properties.

declare namespace React {
  class Component<Props, State> {
    props: Props;
    state: State;
  }
}

Next, create a GreetingProps type that defines a name property of type string and passes it as the type parameter of the Props type parameter:

type GreetingProps = { name: string };

class Greeting extends React.Component<GreetingProps, any> {
  render() {
    return <span>Hello, {this.props.name}!</span>;
  }
}

1) GreetingProps is a type parameter of type parameter Props

2) Similarly, any is a type parameter of the type parameter State

With these types, our components get better type checking and auto-hinting:

However, now when using the React.Component class, you must provide both types. The initial code example we opened no longer typechecks correctly:

// Error: generic type Component<Props, State>
// Requires 2 type parameters.
class Greeting extends React.Component {
  render() {
    return <span>Hello, {this.props.name}!</span>;
  }
}

If we don't want to specify the type like GreetingProps, we can fix the code by providing the any type for the Props and State type parameters:

class Greeting extends React.Component<any, any> {
  render() {
    return <span>Hello, {this.props.name}!</span>;
  }
}

This method allows the compiler to pass, but we have a more elegant approach: the default type of generic parameters.

Generic parameter default type

Starting with TypeScript 2.3, we can add a default type to each generic type parameter. In the following example, if no type parameters are explicitly given, both Props and State are of type any:

declare namespace React {
  class Component<Props = any, State = any> {
    props: Props;
    state: State;
  }
}

Now, we can pass the compiler's check without specifying the generic type:

class Greeting extends React.Component {
  render() {
    return <span>Hello, {this.props.name}!</span>;
  }
}

Of course, we can still explicitly provide a type for the Props type parameter and override the default any type, like this:

type GreetingProps = { name: string };

class Greeting extends React.Component<GreetingProps, any> {
  render() {
    return <span>Hello, {this.props.name}!</span>;
  }
}

Both type parameters now have a default type, so they are optional and we can specify explicit type parameters only for Props:

type GreetingProps = { name: string };

class Greeting extends React.Component<GreetingProps> {
  render() {
    return <span>Hello, {this.props.name}!</span>;
  }
}

Note that we only provide one type parameter. However, the type of the optional type parameter before the omitted one must be specified, otherwise it cannot be omitted.

Other examples

In the previous article about mixin classes in TypeScript 2.2, we initially declared the following two type aliases:

type constructor<T> = new (...args: any[]) => T;
type constructable = Constructor<{}>;

Constructable types are purely syntactic sugar. It can replace the Constructor<{}> type, so you don't have to write the generic type parameters every time. Using default values ​​for generic parameters, you can completely remove the additional constructible type and set {} as the default type.

type Constructor<T = {}> = new (...args: any[]) => T;

The syntax is a little more complicated, but the generated code is more concise, Good.

New --strict major compile option

TypeScript 2.3 introduces a new --strict compiler option that enables a number of other compiler options related to stricter type checking.

New checks added by TypeScript are usually turned off by default to avoid incompatibility with existing projects. While avoiding incompatibilities is a good thing, one downside of this strategy is that it makes configuring for maximum type safety increasingly complex, as new options need to be explicitly added with each TypeScript release. With the --strict compilation option, you can choose the highest level of type safety (understanding that new errors may be reported as newer versions of the compiler add enhanced type checking features).

The new --strict compiler option includes some suggested configuration options for type checking. Specifically, specifying --strict is equivalent to specifying all of the following options (and possibly more in the future):

• --strictNullChecks
• --noImplicitAny
• --noImplicitThis
• --alwaysStrict

Future versions of TypeScript may add additional type checking options to this set. This means we don’t need to monitor every TypeScript version to get new strictness options that should be enabled in our project. If new options are added to the above option sets, they will be automatically activated after upgrading the TypeScript version of your project.

The --strict compiler option sets default values ​​for the compiler options listed above. This means that these options can also be controlled individually. for example:

--strict --noImplicitThis false

Or specify it in the tsconfig.json file:

{
  "strict": true,
  "alwaysStrict": false
}

This will turn on all strict checking options except the --noImplicitThis compiler option. This approach allows you to express strict checks for all items except for some explicitly listed items. In other words, it is now possible to exclude some checks by default at the highest level of type safety.

Improved --init output

In addition to the default --strict setting, tsc --init has improved output. The tsconfig.json file generated by default by tsc --init currently contains some commonly used compiler options commented out with descriptions. You can uncomment the relevant options to get the expected results. We hope that the new output will simplify the configuration of new projects and keep configuration files more readable as your project grows.

The tsc --init compiler can create a configuration file for the build:

$ tsc --init

message TS6071: Successfully created a tsconfig.json file.

After running this command, a tsconfig.json file will be generated in the current working directory. The generated configuration is as follows:

{
  "compilerOptions": {
    /* Basic Options */
    "target": "es5", /* Specify ECMAScript target version: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017', or 'ESNEXT'. */
    "module": "commonjs", /* Specify module code generation: 'commonjs', 'amd', 'system', 'umd' or 'es2015'. */
    // "lib": [], /* Specify library files to be included in the compilation: */
    // "allowJs": true, /* Allow JavaScript files to be compiled. */
    // "checkJs": true, /* Report errors in .js files. */
    // "jsx": "preserve", /* Specify JSX code generation: 'preserve', 'react-native', or 'react'. */
    // "declaration": true, /* Generates corresponding '.d.ts' file. */
    // "sourceMap": true, /* Generates corresponding '.map' file. */
    // "outFile": "./", /* Concatenate and emit output to single file. */
    // "outDir": "./", /* Redirect output structure to the directory. */
    // "rootDir": "./", /* Specify the root directory of input files. Use to control the output directory structure with --outDir. */
    // "removeComments": true, /* Do not emit comments to output. */
    // "noEmit": true, /* Do not emit outputs. */
    // "importHelpers": true, /* Import emit helpers from 'tslib'. */
    // "downlevelIteration": true, /* Provide full support for iterables in 'for-of', spread, and destructuring when targeting 'ES5' or 'ES3'. */
    // "isolatedModules": true, /* Transpile each file as a separate module (similar to 'ts.transpileModule'). */

    /* Strict Type-Checking Options */
    "strict": true /* Enable all strict type-checking options. */
    // "noImplicitAny": true, /* Raise error on expressions and declarations with an implied 'any' type. */
    // "strictNullChecks": true, /* Enable strict null checks. */
    // "noImplicitThis": true, /* Raise error on 'this' expressions with an implied 'any' type. */
    // "alwaysStrict": true, /* Parse in strict mode and emit "use strict" for each source file. */

    /* Additional Checks */
    // "noUnusedLocals": true, /* Report errors on unused locals. */
    // "noUnusedParameters": true, /* Report errors on unused parameters. */
    // "noImplicitReturns": true, /* Report error when not all code paths in function return a value. */
    // "noFallthroughCasesInSwitch": true, /* Report errors for fallthrough cases in switch statement. */

    /* Module Resolution Options */
    // "moduleResolution": "node", /* Specify module resolution strategy: 'node' (Node.js) or 'classic' (TypeScript pre-1.6). */
    // "baseUrl": "./", /* Base directory to resolve non-absolute module names. */
    // "paths": {}, /* A series of entries which re-map imports to lookup locations relative to the 'baseUrl'. */
    // "rootDirs": [], /* List of root folders whose combined content represents the structure of the project at runtime. */
    // "typeRoots": [], /* List of folders to include type definitions from. */
    // "types": [], /* Type declaration files to be included in compilation. */
    // "allowSyntheticDefaultImports": true, /* Allow default imports from modules with no default export. This does not affect code emit, just typechecking. */

    /* Source Map Options */
    // "sourceRoot": "./", /* Specify the location where debugger should locate TypeScript files instead of source locations. */
    // "mapRoot": "./", /* Specify the location where debugger should locate map files instead of generated locations. */
    // "inlineSourceMap": true, /* Emit a single file with source maps instead of having a separate file. */
    // "inlineSources": true, /* Emit the source alongside the sourcemaps within a single file; requires '--inlineSourceMap' or '--sourceMap' to be set. */

    /* Experimental Options */
    // "experimentalDecorators": true, /* Enables experimental support for ES7 decorators. */
    // "emitDecoratorMetadata": true, /* Enables experimental support for emitting type metadata for decorators. */
  }
}

Note that --strict is enabled by default. This means that when you start a new TypeScript project, you are automatically put into the default mode.

Errors in .js files with the --checkJS option

Even with --allowJs, the TypeScript compiler will not report any errors in .js files by default. In TypeScript 2.3, type checking errors in .js files can also be reported using the --checkJs option.

You can skip checking certain files by adding // @ts-nocheck comment to them, and conversely you can choose to check only some .js files without setting --checkJs compile option by adding // @ts-check comment. You can also ignore errors on a specific line by adding // @ts-ignore before the line.

.js files are still checked to ensure only standard ECMAScript features are present, type annotations are only allowed in .ts files and will be flagged as errors in .js files. JSDoc comments can be used to add some type information to your JS code.

The above are the details of TypeScript generic parameter default types and the new strict compilation option. For more information about TypeScript, please pay attention to other related articles on 123WORDPRESS.COM!