Introduction of Typescript

• ECMAScript superset (Stage 3)
• Type checking at compile time
• No overhead introduced (zero dependencies, no extension of JS syntax, no intrusion into the runtime)
• Compile generic, readable JS code

Typescript = Type + ECMAScript + Babel-Lite

Typescript design goals: github.com/Microsoft/T…

The base type

• boolean
• number
• string
• array
• tuple
• enum
• void
• null & undefined
• any & unknown
• never

Correct usage of unknown

We can narrow the unknown type down to a more specific range of types in different ways:

function getLen(value: unknown) :number {
  if (typeof value === 'string') {
    // Value is considered to be a string type because of type protection
  	return value.length
  }
  
  return 0
}
Copy the code

This process is called Type narrowing.

Function types

Function types

Ts also has function types that describe a function:

type FnType = (x: number, y: number) = > number
Copy the code

Function overload?

Because js is a dynamic type, it does not need to support overloading. To ensure type safety, TS supports type overloading of function signatures. That is:

multipleReloading the signatureAnd aTo realize the signature

// Overloaded signature (function type definition)
function toString(x: string) :string;
function toString(x: number) :string;

// Implement signature (function body)
function toString(x: string | number) {
  return String(x)
}

let a = toString('hello') // ok
let b = toString(2) // ok
let c = toString(true) // error
Copy the code

If you defineReloading the signature,To realize the signatureInvisible to the public

function toString(x: string) :string;

function toString(x: number) :string {
  return String(x)
}

len(2) // error
Copy the code

To realize the signatureMust be compatible withReloading the signature

function toString(x: string) :string;
function toString(x: number) :string; // error

// Function implementation
function toString(x: string) {
  return String(x)
}
Copy the code

Reloading the signatureThe types of are not merged

// Overloaded signature (function type definition)
function toString(x: string) :string;
function toString(x: number) :string;

// Implement signature (function body)
function toString(x: string | number) {
  return String(x)
}

function stringOrNumber(x) :string | number {
  return x ? ' ' : 0
}

// Input is the union type of string and number
/ / the string | number
const input = stringOrNumber(1)

toString('hello') // ok
toString(2) // ok
toString(input) // error
Copy the code

Type compatibility

Typescript subtypes are based on structure subtypes, as long as the structure is compatible. (Duck Type)

class Point {
  x: number
}

function getPointX(point: Point) {
  return point.x
}

class Point2 {
  x: number
}

let point2 = new Point2()

getPointX(point2) // OK
Copy the code

Traditional statically typed languages such as Java and c++ are based on nominal subtypes and must display declared subtype relationships (inheritance) to be compatible.

public class Main {
  public static void main (String[] args) {
    getPointX(new Point()); // ok
    getPointX(new ChildPoint()); // ok
    getPointX(new Point1());  // error
  }

  public static void getPointX (Point point) {
    System.out.println(point.x);
  }

  static class Point {
    public int x = 1;
  }

  static class Point2 {
    public int x = 2;
  }
    
  static class ChildPoint extends Point {
    public int x = 3; }}Copy the code

Function subtype

Before introducing function subtypes, let me introduce the concepts of contravariant and covariant. Contravariant and covariant concepts are not unique to TS. They exist in other static languages as well.

Before the introduction, let’s assume a problem. The convention is to mark it as follows:

• A ≼ BIndicates that A is A subtype of B and that A contains all properties and methods of B.
• A => BRepresents A method that takes A and B as the return value.(param: A) => B

If we now have three types of Animal, Dog, and WangCai, then there must be the following relationship:

WangCai ≼ Dog ≼ Animal WangCai ≼ Dog ≼ AnimalCopy the code

Question: Which of the following types is a subclass of Dog => Dog?

• WangCai => WangCai
• WangCai => Animal
• Animal  => Animal
• Animal  => WangCai

Look at it in code

Class Animal {sleep: Function} class Dog extends Animal {// bark: Function} class WangCai extends Dog {dance: Function} Function } function getDogName (cb: (dog: Const Dog = cb(new Dog()) dog.bark()} // For the incoming argument, WangCai is a subclass of Dog, and there is no dance method on Dog. // For an argument, the WangCai class inherits from the Dog class, so there must be a bark method getDogName((WangCai: WangCai) => {wangcai.dance() return new WangCai()}) // For the Animal parameter, there is no bark method on the Animal class, generating an exception. getDogName((wangcai: WangCai) => {wangcai.dance() return new Animal()}); // The WangCai class inherits from the Dog class, so there must be a bark method getDogName(animal: Animal) => {Animal.sleep() return new WangCai()}) => {Animal.sleep() return new WangCai()}) // For the Animal parameter, there is no bark method on the Animal class, generating an exception. getDogName((animal: Animal) => { animal.sleep() return new Animal() })Copy the code

We can see that only Animal => WangCai is a subtype of Dog => Dog. We can conclude that for function types, the type compatibility of function parameters is reversed, which is called contravariant, and the type compatibility of return values is forward, which is called covariant.

The examples of contravariant and covariant only illustrate the case when a function has only one argument. How to distinguish between multiple arguments?

Function arguments can be converted to Tuple type compatibility:

type Tuple1 = [string.number]
type Tuple2 = [string.number.boolean]

let tuple1: Tuple1 = ['1'.1]
let tuple2: Tuple2 = ['1'.1.true]

let t1: Tuple1 = tuple2 // ok
let t2: Tuple2 = tuple1 // error
Copy the code

(Tuple2 => Tuple1); (Tuple2 => Tuple1); (Tuple2 => Tuple1); (Tuple2 => Tuple1); (Tuple2 => Tuple1);

[1.2].forEach((item, index) = > {
	console.log(item)
}) // ok

[1.2].forEach((item, index, arr, other) = > {
	console.log(other)
}) // error
Copy the code

Union types and crossover types

A union type represents multiple types of “or” relationships

function genLen(x: string | any[]) {
  return x.length
}

genLen(' ') // ok
genLen([]) // ok
genLen(1) // error
Copy the code

Crossover types represent multiple types of “and” relationships

interface Person {
  name: string
  age: number
}

interface Animal {
  name: string
  color: string
}

const x: Person & Animal = {
  name: 'x',
  age: 1,
  color: 'red
}
Copy the code

Use union types to represent enumerations

type Position = 'UP' | 'DOWN' | 'LEFT' | 'RIGHT'

const position: Position = 'UP'
Copy the code

You can avoid using enums to invade the runtime.

Typeof keywords

In addition to protecting types, typeof keywords can derive types from implementations.

Note: Typeof is a type keyword and can only be used in type syntax.

function fn(x: string) {
  return x.length
}

const obj = {
  x: 1,
  y: '2'
}

type T0 = typeof fn // (x: string) => number
type T1 = typeof obj // {x: number; y: string }
Copy the code

In the key word

In is also a type keyword that can be traversed over the union type and can only be used under the type keyword.

type Person = {
  [key in 'name' | 'age'] :number
}

// { name: number; age: number; }
Copy the code

A small chestnut

Write a type tool for a type copy:

type Copy<T> = {
  [key in keyof T]: T[key]
}

interface Person {
  name: string
  age: number
}

type Person1 = Copy<Person>
Copy the code

A profound

function createList<T> () :T[] {
  return [] as T[]
}

const numberList = createList<number> ()// number[]
const stringList = createList<string> ()// string[]
Copy the code

With generics support, the createList method can pass in a type and return a typed array instead of an any[].

Under controlled conditions

Extends constraint type, in addition to do can do under controlled conditions, equivalent to a ternary operator, is only for the type.

Expression: T extends U? X : Y

Meaning: return X if T can be assigned to U, Y otherwise. In general, T is said to be assigned to U if T is a subtype of U. For example:

type IsNumber<T> = T extends number ? true : false

type x = IsNumber<string>  // false
Copy the code

There are several built-in mapping types

// Each attribute becomes optional
type Partial<T> = {
  [P inkeyof T]? : T[P] }// Each property becomes read-only
type Readonly<T> = {
  readonly [P in keyof T]: T[P]
}

// Select some properties in the object
type Pick<T, K extends keyof T> = {
  [P in K]: T[P];
}

/ /...
Copy the code

Typescript 2.8 has several mapping types built into lib.d.ts:

• Partial<T>–TAll properties in the
• Readonly<T>–TAll properties in the
• Pick<T, U>– chooseTCan be assigned toUThe type of.
• Exclude<T, U>– fromTCan be assigned toUThe type of.
• Extract<T, U>Extract –TCan be assigned toUThe type of.
• NonNullable<T>– fromTIn rejectingnullandundefined.
• ReturnType<T>— Gets the return type of the function.
• InstanceType<T>Gets the instance type of the constructor type.

So when we write TS, we can use these types of tools directly:

interface ApiRes {
  code: string;
  flag: string;
  message: string;
  data: object;
  success: boolean;
  error: boolean;
}

type IApiRes = Pick<ApiRes, 'code' | 'flag' | 'message' | 'data'>

/ / {
// code: string;
// flag: string;
// message: string;
// data: object;
// }
Copy the code

inferkeywords

Infer can store the types in the operation process. The built-in ReturnType is realized based on this characteristic:

type ReturnType<T> = 
  T extends(... args:any) => infer R ? R : never

type Fn = (str: string) = > number

type FnReturn = ReturnType<Fn> // number
Copy the code

Global modules vs. file modules

By default, we write code that is located under the global module:

const foo = 2
Copy the code

At this point, if we create another file and write the following code, TS considers this to be normal:

const bar = foo // ok
Copy the code

To break this restriction, all you need is an import or export expression in the file:

export const bar = foo // error
Copy the code

Declaration file

Extending native objects

If you’ve written ts, you’re wondering, how do I customize properties on the Window object?

window.myprop = 1 // error
Copy the code

By default, myprop does not exist on Windows, so it is not possible to assign a value directly. Of course, you can use square brackets to assign a value, but you must also use [] for get operations, and there is no type prompt.

window['myprop'] = 1 // OK

window.myprop  // Attribute "myprop" does not exist on type "Window & typeof globalThis"
window['myprop'] // ok, but no prompt, no type
Copy the code

At this point, you can use the declaration file to extend other objects by creating any xxx.d.ts in your project:

// index.d.ts
interface Window {
  myprop: number
}

// index.ts
window.myprop = 2  // ok
Copy the code

It is also possible to extend global objects within modules:

import A from 'moduleA'

window.myprop = 2

declare global {
  interface Window {
    myprop: number}}Copy the code

How to handle non-JS files, for example.vueFile import?

To deal withvuefile

For all files ending in.vue, the vue type can be exported by default, which complies with the rules for vUE single-file components.

declare module '*.vue' {
  import Vue from 'vue'
  export default Vue
}
Copy the code

Handle CSS in JS

For all.css, you can export a value of type any by default, which solves the problem but misses the type checking.

declare module '*.css' {
	const content: any
  export default content
}
Copy the code

import * as React from 'react' import * as styles from './index.css' const Error = () => ( <div ">😭</div> <p className={styles. Title}>Ooooops! </p> <p>This page doesn't exist anymore.</p> </div> ) export default ErrorCopy the code

In fact, both global extension and module extension are based on the feature of TS declaration merging. Simply put, TS will merge some interface, class and type aliases with the same name collected by it according to certain rules.

Common compilation options

When TSC compiles TS code, it takes a different compilation strategy based on the tsconfig.json configuration file options. Here are three common configuration items:

• Target – The JS language version of the generated code, such as ES3, ES5, ES2015, etc.
• Module – The module system that the generated code needs to support, such as ES2015, CommonJS, UMD, etc.
• Lib – Tells TS what features are in the target environment, such as WebWorker, ES2015, DOM, etc.

Like Babel, TS converts only new syntax, not new apis, at compile time, so some scenarios need to handle polyfills themselves.

The output is compiled to a JS file

For AMD and System modules, you can configure the outFile field in tsconfig.json to output a JS file. What if I need to output to another module, such as UMD, and I want to package it into a separate file? You can use rollup or Webpack:

// rollup.config.js
const typescript = require('rollup-plugin-typescript2')

module.exports = {
  input: './index.ts'.output: {
    name: 'MyBundle'.file: './dist/bundle.js'.format: 'umd'
  },
  plugins: [
    typescript()
  ]
}
Copy the code

Learning to recommend

• Typescript Chinese website
• Introduction to Typescript
• github – awesome-typescript
• Zhihu – Come play TypeScript, you’ve got it on!
• Conditional-types-in-typescript (conditional types in TS)