What is Type Assertion in TypeScript?

Hemanta Sundaray

Published December 21, 2023


TypeScript's type system is designed to provide as much static type checking as possible, but there are times when you have more information about the type of a value than TypeScript can infer. This is where type assertion comes in.

By asserting a type, you're essentially telling the compiler, "I know more about the type of this data than you can infer from the code." This can be useful in cases where the type of a variable is not clear to the compiler but is known to you.

For example, when accessing DOM elements, TypeScript's type checker isn't aware of the specific types of elements present in your HTML. However, you might know more about these elements.

Type Assertion Syntax

In TypeScript, a type is asserted using the as keyword followed by the desired type.

Type Assertion Example

Consider a scenario where you are handling exceptions using a try...catch block. You are confident that the error caught in the catch block will be an instance of the Error class. Here's how you can use type assertion:

try {
  // Some operation that might throw an error
} catch (error) {
  console.log((error as Error).message);
}

In this example, error in the catch block is by default typed as any by TypeScript. This is because TypeScript doesn't know the specific type of the error that might be thrown. However, if you are certain that the error will be an instance of the Error class, you can use type assertion to tell TypeScript to treat error as Error.

Type assertion diagram

Here, (error as Error) asserts that error is an instance of Error, thereby allowing access to the Error class's properties, such as message. This ensures that TypeScript understands you are working with an Error object and not just any random object or value.

Note

When you perform a type assertion, TypeScript allows it if either the type you are asserting from or the type you are asserting to is a subset of the other. For instance, you can assert a string as any, because string is a subset of any (since any can be any type, including string). However, you cannot assert a string as number, because string is not a subset of number (and vice versa).

Non-Null Assertion

In TypeScript, nullable types are those that can either hold a value of a specified type T or be null or undefined. The non-null assertion operator allows you to assert that a value is not null or undefined, even when TypeScript's type checker cannot conclude this on its own.

The Non-Null Assertion Operator Syntax

The non-null assertion operator in TypeScript is denoted by the symbol !. When you append ! to any variable or expression, you're telling TypeScript to treat it as if it's not null or undefined.

Non-Null Assertion Operator Example

const header = document.getElementById("header");
// TypeScript can't be sure if 'header' is null or not.
header.style.display = "none";

In this example, the variable header is assigned the result of document.getElementById("header"). TypeScript's type system is aware that this method can return null if no element with the specified ID is found in the document. Therefore, when you try to access the style property of header, TypeScript warns you about a potential issue. You’ll see a red squiggly line under header in the header.style.display = "none"; line.

TypeScript error

When you hover over it, the tooltip will say 'header' is possibly 'null'. This warning is TypeScript's way of telling you that there's a possibility header could be null at runtime, and trying to access its style property could result in a runtime error.

TypeScript error message

To resolve this, you can use the non-null assertion operator (!), which tells TypeScript that you're certain header is not null or undefined. Here's how you'd modify the snippet:

const header = document.getElementById("header");
 
header!.style.display = "none";

By appending ! to header, you inform TypeScript that header will definitely be an element and not null. This removes the TypeScript error, as it now assumes you've handled the nullability check.