Type Assertions and Utility Types

Type Assertions

Type assertions are widely used in TypeScript but should be applied with caution. Unlike const assertions, type assertions do not enforce immutability; rather, they instruct the compiler to treat a value as a specific type, even if TypeScript would normally infer otherwise.

Example:

// Type annotation with a literal value of 72
const myNumber: 72 = 72;
 
// Type assertion changing the perceived type of 72 to 1337
const myObject = 72 as 1337;
// TypeScript now believes 72 is 1337

Although this example may seem impractical, type assertions are particularly useful in test code. When writing tests, you may need to provide complex objects to testing logic, even if only a subset of the properties is required.

For instance, consider a function getName that expects a User object containing both age and name. If a test only requires the name property, manually faking an entire User object would be unnecessary. Using type assertions, you can pass a partial object while ensuring TypeScript accepts it:

type User = {
  age: number;
  name: string;
};
 
function getName(user: User) {
  return user.name;
}
 
const userAssertion = { name: 'Benny' } as User;
 
getName(userAssertion);

Type Assertions and the Bottom Type

A common pattern with type assertions involves using the bottom type (unknown), especially when working with more complex or uncertain types. By asserting a value as unknown, you can later cast it to any other type you choose, enabling the assertion between different collective types:

const myLuckyNumber = 72 as string; // ❌ Error
const myLuckyNumber = 72 as unknown as string; // ✅ Valid

Utility Types

Instead of forcing TypeScript to accept an incomplete test object, we can use built-in utility types to enforce stricter and safer typings. These utility types are a core feature of TypeScript and may vary depending on the TypeScript version in use. They are globally available and included in the bundled library declaration files, which are determined by the "lib" option in your tsconfig.json file (TypeScript project settings). Let's explore some essential and commonly used utility types.

Pick<T, K>

With the built-in utility type Pick, we can specify that the getName function should only consider the name property. This approach eliminates the need for type assertions, which are generally best avoided to preserve TypeScript's compiler safety by respecting its type inference:

type User = {
  age: number;
  name: string;
};
 
function getName(user: Pick<User, 'name'>) {
  return user.name;
}
 
const userAssertion = { name: 'Benny' };
 
getName(userAssertion);

Partial<T>

For greater flexibility while retaining type information, Partial<User> makes all properties optional. This utility type transforms every property in a given type into an optional one:

type User = {
  age: number;
  name: string;
};
 
// Equivalent to:
type PartialUser = {
  age?: number;
  name?: string;
};
 
// Using the utility type directly:
type UtilitySyntax = Partial<User>;

Omit<T, K>

type User = {
  id: number;
  name: string;
  email: string;
};
 
// Remove 'email' from User
type UserWithoutEmail = Omit<User, 'email'>;
 
const user: UserWithoutEmail = { id: 1, name: 'Benny' };

Required<T>

The Required utility type marks all properties of a type as required:

type User = {
  id: number;
  name?: string;
};
 
// Ensure all properties are required
type RequiredUser = Required<User>;
 
// User must include 'name'
const user: RequiredUser = { id: 1, name: 'Benny' };

Readonly<T>

Readonly makes all properties of a type immutable:

type User = {
  id: number;
  name: string;
};
 
const user: Readonly<User> = { id: 1, name: 'Benny' };
 
user.name = 'John'; // ❌ Error

Record<K, T>

The Record type creates an object type where all keys are of type K and all values are of type T:

type Access = 'create' | 'delete' | 'view';
 
// Define role-based access with 'Record'
const permissions: Record<Access, boolean> = {
  create: false,
  delete: false,
  view: true,
};

Exclude<T, U>

As the name suggests, Exclude removes specific types from a given type:

type Status = 'success' | 'error' | 'pending';
 
// Exclude 'pending'
type CompletedStatus = Exclude<Status, 'pending'>;
 
const success: CompletedStatus = 'success'; // ✅ Valid
const pending: CompletedStatus = 'pending'; // ❌ Error

Uppercase<T>

The Uppercase<StringType> is a built-in utility type that transforms all characters in a given string literal type to uppercase:

type LowerCaseString = 'hello world';
type UpperCaseString = Uppercase<LowerCaseString>; // "HELLO WORLD"

This is just a small selection of utility types. Please refer to the official TypeScript documentation about utility types to construct your own types out of existing types.

What You Have Learned

Type Assertions and Their Use Cases: You have learned that type assertions allow you to override TypeScript’s type inference, instructing the compiler to treat a value as a specific type. While useful in testing scenarios, they should be used cautiously to guarantee type safety.

Utility Types for Safer Typing: Instead of relying on type assertions, you now understand that utility types like Pick<T, K> and Partial<T> provide safer ways to handle object structures by selecting or modifying specific properties dynamically.

Modifying Object Properties with Utility Types: You have seen how Omit<T, K> removes properties, Required<T> makes all fields mandatory, and Readonly<T> prevents modifications, ensuring better type safety and code maintainability.

Creating Dynamic Object Types: You now know how Record<K, T> defines object types with specific key-value mappings, and how Exclude<T, U> removes specific values from a union type, allowing more precise type definitions.

String Manipulation with Utility Types: You have explored how TypeScript’s built-in string utility types, such as Uppercase<T>, can transform string literals at the type level, enabling better control over text-based type constraints.

Quiz

What is the primary purpose of type assertions in TypeScript?

• a) To force TypeScript to enforce immutability on a value.
• b) To tell the TypeScript compiler to treat a value as a specific type.
• c) To dynamically check a variable’s type at runtime.
• d) To convert a TypeScript object into a JavaScript object.

Why should type assertions be used cautiously in TypeScript?

• a) They can change the actual value of a variable at runtime.
• b) They can override TypeScript’s type inference, leading to potential runtime errors.
• c) They prevent the compiler from performing any further type checking.
• d) They make variables immutable, preventing modification.

Which of the following statements best describes the role of utility types in TypeScript?

• a) They allow you to modify existing types in a structured way without manually redefining them.
• b) They automatically infer the type of every variable, eliminating the need for annotations.
• c) They are used to bypass TypeScript’s type checking and allow dynamic typing.
• d) They replace all explicit type declarations in TypeScript projects.

Which utility type makes all properties in a type immutable?

• a) Required<T>
• b) Readonly<T>
• c) Omit<T, K>
• d) Pick<T, K>

Which of the following is a key difference between using a utility type like Pick<T, K> and a type assertion?

• a) Pick<T, K> enforces the inclusion of specific properties while preserving TypeScript’s type safety, unlike type assertions, which override the compiler’s type inference.
• b) Type assertions are checked at runtime, whereas Pick<T, K> is only used in design time.
• c) Utility types modify values at runtime, while type assertions modify them at compile time.
• d) Using a utility type like Pick<T, K> removes type safety, whereas type assertions enforce stricter type checking.

When dealing with incomplete objects in tests, what is a safer alternative to using a type assertion?

• a) Using the any type to disable type checking.
• b) Using a utility type like Pick<T> to require only certain properties instead of forcing a type assertion.
• c) Manually defining every possible property in the test object.
• d) Ignoring TypeScript errors by disabling the compiler in "tsconfig.json".