Explain TypeScript mapped types and better literal type inference

Overview

TypeScript 2.1 introduced mapped types, a powerful addition to the type system. Essentially, mapped types allow us to create new types from existing types by mapping attribute types. Converts each property of an existing type according to the rules we specify. The converted attributes form the new type.

Using mapped types, you can capture the effects of methods like Object.freeze() in the type system. Once an object is frozen, you can no longer add, change, or delete properties from it. Let's see how this can be encoded in the type system without using mapped types:

interface Point {
  x: number;
  y: number;
}

interface FrozenPoint {
  readonly x: number;
  readonly y: number;
}

function freezePoint(p: Point): FrozenPoint {
  return Object.freeze(p);
}

const origin = freezePoint({ x: 0, y: 0 });

// Error! Cannot assign to 'x' because it
// is a constant or a read-only property.
origin.x = 42;

We define a Point interface that contains two properties, x and y. We also define another interface, FrozenPoint, which is the same as Point, except that all its properties are defined as read-only properties using readonly.

The freezePoint function accepts a Point as an argument and freezes it, then returns the same object to the caller. However, the type of the object has been changed to FrozenPoint, so its properties are statically typed as read-only. That’s why TypeScript will error when trying to assign 42 to the x property. At runtime, the assignment will either throw a TypeError (strict mode) or fail silently (non-strict mode).

While the above example compiles and works correctly, it has two major drawbacks:

• Two interfaces are required. In addition to the Point type, you must also define the FrozenPoint type so that the readonly modifier can be added to both properties. When we change Point, we also have to change FrozenPoint, which is error-prone and annoying.
• The freezePoint function is required. For each type of object that we want to freeze in our application, we must define a wrapper function that accepts an object of that type and returns an object of the frozen type. Without a mapped type, we can't use Object.freeze() statically in a generic way.

Using mapped types to construct Object.freeze()

Let’s take a look at how Object.freeze() is defined in the lib.d.ts file:

/**
  * Prevents the modification of existing property attributes and values, and prevents the addition of new properties.
  * @param o Object on which to lock the attributes.
  */
freeze<T>(o: T): Readonly<T>;

The return type of this method is Readonly<T>, which is a mapping type and is defined as follows:

type Readonly<T> = {
  readonly [P in keyof T]: T[P]
};

This syntax can be daunting at first, so let's break it down step by step:

• A generic Readonly is defined with a type parameter named T.
• Within the square brackets, the keyof operator is used. keyof T represents all property names of type T as a union of string literal types.
• The in keyword within the square brackets indicates that we are dealing with a mapped type. [P in keyof T]: T[P] means converting the type of each property P of type T to T[P]. Without the readonly modifier, this would be an identity cast.
• Type T[P] is a lookup type that represents the type of a property P of type T.
• Finally, the readonly modifier specifies that each property should be converted to a read-only property.

Because the Readonly<T> type is generic, every type we provide for T is correctly wrapped in Object.freeze().

const origin = Object.freeze({ x: 0, y: 0 });

// Error! Cannot assign to 'x' because it
// is a constant or a read-only property.
origin.x = 42;

The syntax of the mapping type is more intuitive

This time we use the Point type as an example to roughly explain how type mapping works. Please note that the following is for explanation purposes only and does not accurately reflect the parsing algorithm used by TypeScript.

Start with the type alias:

type ReadonlyPoint = Readonly<Point>;

Now, we can replace the Point type for the generic type T in Readonly<T>:

type ReadonyPoint = {
  readonly [P in keyof Point]: Point[P]
};

Now that we know that T is Point, we can determine the union of the string literal types represented by keyof Point:

type ReadonlyPoint = {
  readonly [P in "x" | "y"]: Point[p]
};

Type P represents each property x and y. Let's write them as separate properties, removing the mapped type syntax.

type ReadonlyPoint = {
  readonly x: Point["x"];
  readonly y: Point["y"];
};

Finally, we can parse the two lookup types and replace them with the concrete x and y types, both of which are numbers.

type ReadonlyPoint = {
  readonly x: number;
  readonly y: number;
};

Finally, the resulting ReadonlyPoint type is the same as the FrozenPoint type we created manually.

More examples of mapping types

We have already seen the built-in Readonly<T> type in the lib.d.ts file above. Additionally, TypeScript defines other mapped types that are useful in a variety of situations. as follows:

/**
 * Make all properties in T optional
 */
type Partial<T> = {
  [P in keyof T]?: T[P]
};

/**
 * From T pick a set of properties K
 */
type Pick<T, K extends keyof T> = {
  [P in K]: T[P]
};

/**
 * Construct a type with a set of properties K of type T
 */
type Record<K extends string, T> = {
  [P in K]: T
};

Here are two more examples of mapping types, you can write your own if you want:

/**
 * Make all properties in T nullable
 */
type Nullable<T> = {
  [P in keyof T]: T[P] | null
};

/**
 * Turn all properties of T into strings
 */
type Stringify<T> = {
  [P in keyof T]: string
};

Combinations of mapped types and unions are also interesting:

type X = Readonly<Nullable<Stringify<Point>>>;
// type X = {
// readonly x: string | null;
// readonly y: string | null;
// };

Real-world use cases for mapping types

Mapping types are often seen in practice. Let’s take a look at react and Lodash:

• The setState method of a react:component allows us to update the entire state or a subset of it. We can update as many properties as we want, which makes the setState method a great use case for Partial<T>.
• Lodash: The pick function selects a set of properties from an object. This method returns a new object that contains only the properties we selected. This behavior can be built using Pick<T>, as its name suggests.

Better type inference for literals

String, numeric, and boolean literal types (e.g. "abc", 1, and true) were previously inferred only when an explicit type annotation was present. Starting with TypeScript 2.1, literal types are always inferred to have default values. In TypeScript 2.0, the type system was extended with several new literal types:

• boolean literal type
• Numeric literals
• Enumeration literals

The type of a const variable or readonly property without a type annotation is inferred to be the type of the literal initializer. The type of an initialized let variable, var variable, parameter, or non-readonly property without a type annotation is inferred to be the expanded literal type of the initial value. The extended type of a string literal is string, the extended type of a number literal is number, the extended type of a true or false literal is boolean, and the extended type of an enumeration literal is enumeration.

Better const variable inference

Let's start with local variables and the var keyword. When TypeScript sees the following variable declaration, it infers that the baseUrl variable is of type string:

var baseUrl = "https://example.com/";
// Inferred type: string

The same is true for variables declared with the let keyword

let baseUrl = "https://example.com/";
// Inferred type: string

Both variables are inferred to be of type string because they can change at any time. They are initialized with a literal string value, but they can be modified later.

However, if you declare a variable with the const keyword and initialize it with a string literal, the inferred type is no longer string but the literal type:

const baseUrl = "https://example.com/";
// Inferred type: "https://example.com/"

Since the value of a constant string variable never changes, the inferred type is more specific. The baseUrl variable cannot hold any other value than "https://example.com/".

Literal type inference also works for other primitive types. If you initialize a constant with a direct numeric or Boolean value, the literal type is inferred:

const HTTPS_PORT = 443;
// Inferred type: 443

const rememberMe = true;
// Inferred type: true

Similarly, when the initializer is an enumeration value, the literal type is inferred:

enum FlexDirection {
  Row,
  Column
}

const direction = FlexDirection.Column;
// Inferred type: FlexDirection.Column

Note that the direction type is FlexDirection.Column, which is an enumeration literal type. If you use the let or var keyword to declare a direction variable, its inferred type should be FlexDirection.

Better read-only property inference

Similar to local const variables, read-only properties with literal initializers are also inferred to have a literal type:

class ApiClient {
  private readonly baseUrl = "https://api.example.com/";
  // Inferred type: "https://api.example.com/"

  get(endpoint: string) {
    // ...
  }
}

Read-only class properties can only be initialized immediately or in the constructor. Attempting to change the value elsewhere will result in a compile-time error. Therefore, it is reasonable to infer the literal type of a read-only class property, since its value does not change.

Of course, TypeScript has no idea what happens at runtime: a property marked with readonly can be changed at any time by some JavaScript code. The readonly modifier only restricts access to the property from TypeScript code, it does nothing at runtime. That is, it will be deleted during compilation and will not appear in the generated js code.

Usefulness of inferred literal types

You might ask yourself why inferring literal types for const variables and readonly properties is useful. Consider the following code:

const HTTP_GET = "GET"; // Inferred type: "GET"
const HTTP_POST = "POST"; // Inferred type: "POST"

function get(url: string, method: "GET" | "POST") {
  // ...
}

get("https://example.com/", HTTP_GET);

If the inferred type of the HTTP_GET constant was string instead of "GET", you would get a compile-time error because you cannot pass HTTP_GET as the second argument to the get function:

Argument of type 'string' is not assignable to parameter of type '"GET" | "POST"'

Of course, passing arbitrary strings as function arguments is not allowed if the corresponding argument only allows two specific string values. However, when the literal types "GET" and "POST" are inferred for the two constants, everything works out.

The above is a detailed explanation of TypeScript mapping types and better literal type inference. For more information about TS, please pay attention to other related articles on 123WORDPRESS.COM!