Shulou(Shulou.com)06/03 Report--

This article mainly introduces "what is the literal type of template in TypeScript 4.1". In daily operation, I believe that many people have doubts about the literal type of template in TypeScript 4.1. the editor consulted all kinds of data and sorted out simple and easy-to-use methods of operation. I hope it will be helpful for you to answer the question of "what is the literal type of template in TypeScript 4.1". Next, please follow the editor to study!

New language features

Template literal type

Since ES6, we have been able to write strings in backquotes, not just single or double quotes, through the template literal (Template Literals) feature:

Const message = `text`

As Flavio Copes said, template literals provide features that previously quoted strings do not have:

It is very convenient to define multiline strings

Variables and expressions can be easily interpolated

You can use template tags to create DSL (Domain Specific Language, domain specific language)

The template literal type is exactly the same as the template string syntax in JavaScript, but is used in the type definition:

Type Entity = 'Invoice'; type Notification = `${Entity} saved`; / / equivalent to / / type Notification =' Invoice saved'; type Viewport = 'md' |' xs'; type Device = 'mobile' |' desktop'; type Screen =` ${Viewport | Device} screen`; / / equivalent to the following line / / type Screen ='md screen' |'xs screen' | 'mobile screen' |' desktop screen'

When we define a specific literal type, TypeScript generates a new string literal type by stitching the content.

Remapping of key values to keys in a type (Key Remapping)

Mapping types can create new object types based on any key. The literal amount of the string can be used as the attribute name in the mapping type:

Type Actions = {[K in 'showEdit' |' showCopy' | 'showDelete']?: boolean;}; / / equivalent to type Actions = {showEdit?: boolean, showCopy?: boolean, showDelete?: boolean}

If you want to create new keys or filter out keys, TypeScript 4.1allows you to remap keys in the mapping type using the new as clause:

Type MappedTypeWithNewKeys = {[K in keyof T as NewKeyType]: t [K]}

TypeScript Remapping KeysThe new as clause lets you leverage features like template literal types to easily create new property names based on old ones. Keys can be filtered by producing never so that you don't have to use an extra Omit helper type in some cases: by using the new as clause, we can easily create new attribute names based on old attributes using features such as template literal types. We can filter the keys by outputting never so that in some cases we do not have to use additional Omit helper types:

Type Getters = {[K in keyof T as `get$ {Capitalize} `]: () = > T [K]}; interface Person {name: string; age: number; location: string;} type LazyPerson = Getters; / / ^ = type LazyPerson = {/ / getName: () = > string; / / getAge: () = > number; / / getLocation: () = > string / / remove the 'kind' attribute type RemoveKindField = {[Kin keyof T as Exclude]: t [K]}; interface Circle {kind: "circle"; radius: number;} type KindlessCircle = RemoveKindField; / / ^ = type KindlessCircle = {/ / radius: number; / /}

TypeScript utilizes template text types with as clauses (source)

JSX factory function

JSX stands for JavaScript XML, which allows us to write HTML elements in JavaScript and place them in DOM without any createElement () or appendChild () methods, such as:

Const greeting = Yes I can do itinerary; ReactDOM.render (greeting, document.getElementById ('root'))

TypeScript 4.1 supports the jsx and jsxs factory functions of React 17 through two new options for the compiler option jsx:

React-jsx

React-jsxdev

"these options are used for production and development compilation, respectively. In general, one option can be extended from another." -TypeScript release instructions

Here are two examples of two TypeScript configuration documents for production and development:

/. / src/tsconfig.json {"compilerOptions": {"module": "esnext", "target": "es2015", "jsx": "react-jsx", "strict": true}, "include": [. / * * / *]}

Development configuration:

/. / src/tsconfig.dev.json {"extends": ". / tsconfig.json", "compilerOptions": {"jsx": "react-jsxdev"}}

As shown in the following figure, TypeScript 4.1 supports type checking in JSX environments such as React:

Recursive condition type

Another new feature is recursive conditional types, which allow them to reference themselves in branches, making it more flexible to deal with conditional types and making it easier to write recursive type aliases. Here is an example of using Awaited to unfold a deeply nested Promise:

Type Awaited = T extends PromiseLike? Awaited: t; / / similar to `promise.then (...) `, but more precise in type declare function customThen (p: Promise, onFulfilled: (value: Awaited) = > U): Promise

It should be noted, however, that TypeScript needs more time for type checking of recursive types. Microsoft warns that they should be used responsibly and cautiously.

Checked indexed accesses index access check

The index signature in _ TypeScript allows you to access any named property as in the following Options interface:

Interface Options {path: string; permissions: number; / / Extra properties are caught by this index signature. / / additional attributes will be used by this [propName: string]: string | number;} function checkOptions (opts: Options) {opts.path; / / string opts.permissions; / / number / / all of these are fine! Because all types are string | number opts.yadda.toString (); opts ["foo bar baz"] .toString (); opts [Math.random ()] .toString ();}

Here, we see that attributes that are not path and permissions should have string | number type:

TypeScript 4.1provides a new flag, noUncheckedIndexedAccess, so that every property access (such as opts.path) or index access (such as opts ["blabla"]) may not be defined. This means that if we need to access properties such as opts.path in the previous example, we must check for its existence or use the non-null assertion operator (suffix! Characters):

Function checkOptions (opts: Options) {opts.path; / / string opts.permissions; / / number / / the following code is illegal opts.yadda.toString () when noUncheckedIndexedAccess is opened; opts ["foo bar baz"]. ToString (); opts [Math.random ()] .toString (); / / check whether the attribute really exists if (opts.yadda) {console.log (opts.yadda.toString ()) } / / directly use the non-empty assertion operator opts.yaddaasser.toString ();}

The noUncheckedIndexedAccess flag is useful for catching a lot of errors, but it can be noisy for a lot of code. That's why-- the strict switch doesn't enable it automatically.

BaseUrl is not required to specify a path

Prior to TypeScript 4.1, to be able to use paths in the tsconfig.json file, the baseUrl parameter must be declared. In the new version, you can specify baseUrl without the paths option. This solves the problem of poor path in automatic import.

{"compilerOptions": {"baseUrl": ". / src", "paths": {"@ shared": ["@ shared/"] / / This mapping is relative to "baseUrl"}

CheckJs turns on allowJs by default

If you have a JavaScript project where you are using the checkJs option to check for errors in the .js file, you should also declare allowJs to allow the JavaScript file to be compiled. In TypeScript 4.1, checkJs means allowJs by default:

{compilerOptions: {allowJs: true, checkJs: true}}

Editor support for JSDoc @ see tags

When using TypeScript in the editor, there is now better support for the JSDoc tag @ see, which will improve the usability of TypeScript 4.1:

/ / @ filename: first.ts export class C {} / / @ filename: main.ts import * as first from ". / first"; / * * @ see first.C * / function related () {}

Incompatible change

Lib.d.ts change

Structure and DOM's environment declaration make it easy for you to start writing type-checked JavaScript code.

This file is automatically included in the compilation context of the TypeScript project. You can exclude it by specifying the-- noLib compiler command-line flag or by configuring noLib to true in tsconfig.json.

In TypeScript 4.1, because the DOM type is automatically generated, the lib.d.ts may have a set of altered API, such as Reflect.enumerate removed from the ES2016.

Abstract members cannot be marked as async

In another major change, members marked as abstract can no longer be marked as async. Therefore, to fix your code, you must remove the async keyword:

Abstract class MyClass {/ / async abstract async create (): Promise;} must be deleted in TypeScript 4.1

Any/unknown spreads outward

Before TypeScript 4. 1, for expressions like foo & & somethingElse, the type of foo was any or unknown. The type of the entire expression will be of type somethingElse, which in the following example is {someProp:string}:

Declare let foo: unknown; declare let somethingElse: {someProp: string}; let x = foo & & somethingElse

In TypeScript 4.1, both any and unknown will spread outward, not on the right. Typically, the appropriate solution to this change is to switch from foo & & someExpression to! foo & & someExpression.

Note: double exclamation point (!!) Is an easy way to cast a variable to a Boolean value (true or false).

The parameter of resolve in Promise is no longer optional.

The parameters for resolve in Promise are no longer optional, such as the following code:

New Promise ((resolve) = > {doSomethingAsync () = > {doSomething (); resolve ();});})

This code will report an error when compiled in TypeScript 4.1:

Resolve () ~ error TS2554: Expected 1 arguments, but got 0. An argument for 'value' was not provided.

To solve this problem, you must provide at least one value to resolve in Promise, otherwise, if you really need to call resolve () without arguments, you must declare Promise with an explicit void generic type parameter:

New Promise ((resolve) = > {doSomethingAsync () = > {doSomething (); resolve ();});})

Conditional expansion will create optional attributes

In JavaScript, the expansion operator {... files} does not act on false values, such as files is null or undefined.

In the following example using conditional propagation, if file is defined, the properties of file.owner are propagated. Otherwise, no properties are propagated to the returned object:

Function getOwner (file?: File) {return {... file?.owner, defaultUserId: 123,};}

Prior to TypeScript 4.1, getOwner returned the federation type based on each expanded object:

{x: number} | {x: number, name: string, age: number, location: string}

If file is defined, all attributes from Person (owner's type) are owned.

Otherwise, none of the results will be shown

But it turns out that the cost turns out to be very high and often useless. There are hundreds of expanded objects in a single object, and each expanded object may add hundreds or thousands of attributes. For better performance, in TypeScript 4.1, the returned types sometimes use all optional properties:

{x: number; name?: string; age?: number; location?: string;}

Mismatched parameters will no longer be associated

In the past, parameters that did not correspond to each other were associated with each other in TypeScript by associating them with the any type.

In the following overloaded example, which provides multiple functional types for the same function, the pickCard function returns two different contents based on what the user passes in. If the user passes in an object that represents deck, the function selects card. If users choose card, they will get the card of their choice:

Let suits = ["hearts", "spades", "clubs", "diamonds"]; function pickCard (x: {suit: string; card: number} []): number; function pickCard (x: number): {suit: string; card: number} Function pickCard (x: any): any {/ / Check to see if we're working with an object/array / / if so, they gave us the deck and we'll pick the card if (typeof x = = "object") {let pickedCard = Math.floor (Math.random () * x.length); return pickedCard;} / / Otherwise just let them pick the card else if (typeof x = = "number") {let pickedSuit = Math.floor (x / 13) Return {suit: suits [pickedSuit], card: X% 13};}} let myDeck = [{suit: "diamonds", card: 2}, {suit: "spades", card: 10}, {suit: "hearts", card: 4},]; let pickedCard1 = myDeck [pickcard (myDeck)]; alert ("card:" + pickedCard1.card + "of" + pickedCard1.suit); let pickedCard2 = pickCard (15) Alert ("card:" + pickedCard2.card + "of" + pickedCard2.suit)

With TypeScript 4. 1, assignments will fail in some cases, and overloaded parsing will fail in some cases. The solution is that it is best to use type assertions to avoid errors.

At this point, the study on "what are the literal types of templates in TypeScript 4.1" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.