Notice: This page requires JavaScript to function properly.
Please enable JavaScript in your browser settings or update your browser.
Aprenda Type Assertions | Type Inference and Advanced Type Safety
TypeScript Types Fundamentals

bookType Assertions

When TypeScript cannot determine a specific type, or when you know more about a value than TypeScript does, you can use a type assertion to tell the compiler how to treat a value. Type assertions use the as keyword to override TypeScript's inferred type.

12345
// TypeScript infers the type of value as unknown let value: unknown = "Hello, TypeScript!"; // You know value is a string, so you assert its type let strLength: number = (value as string).length;
copy

In the example above, value is declared as unknown. TypeScript does not allow you to access string properties or methods on an unknown type, so you must assert that value is a string before accessing its length property. You do this with (value as string), allowing you to safely use string-specific features.

Type assertions do not perform any runtime checks or type conversions—they simply tell the compiler to trust you. This means that if you assert an incorrect type, you might introduce bugs that TypeScript cannot catch. For example, asserting a value to a type it does not actually have can lead to runtime errors.

To use type assertions safely, follow these best practices:

  • Use type assertions only when you are certain about the value's type;
  • Avoid asserting to types that are completely unrelated;
  • Prefer narrowing types with type guards or control flow when possible, instead of relying on assertions;
  • Use assertions to help TypeScript understand complex code, not to bypass safety checks.

Always remember that type assertions are a tool for working with TypeScript's static analysis, not a substitute for proper type safety.

question mark

Which of the following is a safe and appropriate use of a type assertion in TypeScript?

Select the correct answer

Tudo estava claro?

Como podemos melhorá-lo?

Obrigado pelo seu feedback!

Seção 3. Capítulo 4

Pergunte à IA

expand

Pergunte à IA

ChatGPT

Pergunte o que quiser ou experimente uma das perguntas sugeridas para iniciar nosso bate-papo

Awesome!

Completion rate improved to 8.33

bookType Assertions

Deslize para mostrar o menu

When TypeScript cannot determine a specific type, or when you know more about a value than TypeScript does, you can use a type assertion to tell the compiler how to treat a value. Type assertions use the as keyword to override TypeScript's inferred type.

12345
// TypeScript infers the type of value as unknown let value: unknown = "Hello, TypeScript!"; // You know value is a string, so you assert its type let strLength: number = (value as string).length;
copy

In the example above, value is declared as unknown. TypeScript does not allow you to access string properties or methods on an unknown type, so you must assert that value is a string before accessing its length property. You do this with (value as string), allowing you to safely use string-specific features.

Type assertions do not perform any runtime checks or type conversions—they simply tell the compiler to trust you. This means that if you assert an incorrect type, you might introduce bugs that TypeScript cannot catch. For example, asserting a value to a type it does not actually have can lead to runtime errors.

To use type assertions safely, follow these best practices:

  • Use type assertions only when you are certain about the value's type;
  • Avoid asserting to types that are completely unrelated;
  • Prefer narrowing types with type guards or control flow when possible, instead of relying on assertions;
  • Use assertions to help TypeScript understand complex code, not to bypass safety checks.

Always remember that type assertions are a tool for working with TypeScript's static analysis, not a substitute for proper type safety.

question mark

Which of the following is a safe and appropriate use of a type assertion in TypeScript?

Select the correct answer

Tudo estava claro?

Como podemos melhorá-lo?

Obrigado pelo seu feedback!

Seção 3. Capítulo 4
some-alt