Definition: Type Assertion can be used to manually specify the Type of a value.

For compatibility, it is recommended that you use the value as type syntax when using type assertions.

  • The purpose of type assertions

    • Assert a union type as one of the types.

      When TypeScript doesn’t know what type a variable of a union type is, we can only access properties or methods that are common to all types of the union type, and sometimes we really need to access properties or methods that are specific to one of those types without determining the type. We specify it as a type using assertions. (This only “tricks” the TS into trusting the type we specify.)

      interface Cat {
    name: string;
    run(): void;
}
interface Fish {
    name: string;
    swim(): void;
}

function isFish(animal: Cat | Fish) {
    if (typeof (animal as Fish).swim === 'function') {
        return true;
    }
    return false; } interface Cat {name: string; run(): void; } interface Fish { name: string; swim(): void; }function swim(animal: Cat | Fish) {
    (animal as Fish).swim();
}

const tom: Cat = {
    name: 'Tom'.run() { console.log('run')}}; swim(tom); // Uncaught TypeError: animal.swim is not afunction`
Copy the code

    • Assert a parent class as a more concrete subclass

      class ApiError extends Error { code: number = 0; } class HttpError extends Error { statusCode: number = 200; } // Use this function to determine what the Error type is // The type of its argument is the abstract parent class Error, so this function can accept Error or its subclass as an argument // But because the parent class Error has no code attribute, it will report an Error, Type assertion is required to get (error as ApiError).codefunction isApiError(error: Error) {
      if (typeof (error as ApiError).code === 'number') {
        return true;
    }
    return false;
}
Copy the code

    To be honest, instanceof is more appropriate for determining the parent class of a subclass. But sometimes ApiError and HttpError are not real classes, they are just interfaces, not real values, and they are removed after being js and cannot be determined using instanceof:

      interface ApiError extends Error {
      code: number;
  }
  interface HttpError extends Error {
      statusCode: number;
  }
  
  function isApiError(error: Error) {
      if (error instanceof ApiError) {
          return true;
      }
      return false;
  }
Copy the code

    • Assert any type as any

    window.foo = 1; Foo = 1; // We are pretty sure that this code does not fail, but ts compiles with an error (window as any).Copy the code

    This feature cannot be abused. But it can be used.

    • Assert any as a concrete type

    Some functions in the library return any, either because of history or because the previous programmer who wrote the library was incompetent. If left unmanaged, type inference leads to more any, and it is appropriate to use it to assert specific types rather than letting it evolve. Assert it as a concrete type when we use it

    function getCacheData(key: string): any {
    return (window as any).cache[key];
}

interface Cat {
    name: string;
    run(): void;
}

const tom = getCacheData('tom') as Cat;
tom.run()
Copy the code