Global Scope

The `Prettify` helper is a utility type that takes an object type and makes the hover overlay more readable.

```ts
type Prettify<T> = {
  [K in keyof T]: T[K];
} & {};
```

It's known by various names - `Id`, `Compute`, `Unwrap` - but each uses this same implementation.

It's also not globally available in TypeScript - you'll need to define it yourself using the code above.

## Example

Let's imagine that you've got a type with multiple intersections:

```typescript
type Intersected = {
  a: string;
} & {
  b: number;
} & {
  c: boolean;
};
```

If you hover over `Intersected`, you'll see the following:

```typescript
/**
 * { a: string; } & { b: number; } & { c: boolean; }
 */
```

This is a little ugly. But we can wrap it in `Prettify` to make it more readable:

```typescript
type Intersected = Prettify<
  {
    a: string;
  } & {
    b: number;
  } & {
    c: boolean;
  }
>;

/**
 * {
 *   a: string;
 *   b: number;
 *   c: boolean;
 * }
 */
```

Much better. This also works on more complex computations, as the [Remix team discovered](https://twitter.com/pcattori/status/1660648097985224705).

## Why This Works

It's not clear why using a mapped type and intersecting it with `{}` actually works. It's a quirk of the TypeScript compiler.

Oddly, intersecting it with `unknown` also works:

```typescript
type Prettify<T> = {
  [K in keyof T]: T[K];
} & unknown;
```

Does this make it likely to break in the future? No - TypeScript has tests to ensure that this code won't break, so you can consider `Prettify` safe to use.


The `Prettify` Helper

Mapped types are a feature in TypeScript which allow you to map over a union of types to create a new type.

The syntax looks like this:

```typescript
type Fruit = "apple" | "banana" | "orange";

type NewType = {
  [F in Fruit]: {
    name: F;
  };
};
/**
 * {
 *   apple: { name: "apple" };
 *   banana: { name: "banana" };
 *   orange: { name: "orange" };
 * }
 */
```

Let's break down each piece of syntax we're seeing here. The `F in Fruit` acts as a kind of index signature, which allows us to loop over each member of the `Fruit` union. You can think of this as being similar to a JavaScript `for...of` loop:

```typescript
const fruit = ["apple", "banana", "orange"];

for (const f of fruit) {
  console.log(f);
}
```

In both cases, we get a very important thing: a closure over the current thing we're iterating over. In the JavaScript example, we get the current item. In the TypeScript example, we get the current member of the union.

This ability to cleanly map over each member of a union in a simple `for...of` model is what makes mapped types so powerful.

## With `keyof`

Using the `keyof` operator with mapped types gives you a smooth API to create object types _from_ other object types.

```typescript
interface Person {
  name: string;
  age: number;
}

type NullablePerson = {
  [P in keyof Person]: Person[P] | null;
};

/**
 * {
 *   name: string | null;
 *   age: number | null;
 * }
 */
```

Here, we gain access to `P`, which represents either `name` the first time this is iterated over, then `age` the second time. This means we can gain access to the type of each property's value in `Person` by using `Person[P]`.

We can then use this to create a new type that has the same keys and values as `Person` but with each property being nullable.

## Mapping non-string unions with `as`

Sometimes, you'll have a union of things which can't be assigned to the key of an object. For instance, a union of objects:

```typescript
type Event =
  | {
      type: "click";
      x: number;
      y: number;
    }
  | {
      type: "hover";
      element: HTMLElement;
    };
```

Here, you can see that `Event` is a union of two objects. If we tried to do `[E in Event]`, we'd get an error:

```typescript
type EventMap = {
  // Type 'Event' is not assignable to type 'string | number | symbol'.
  [E in Event]: (event: E) => void;
};
```

To get around this, we can use the `as` keyword to tell TypeScript that we want to use the `type` property of each `E` as we iterate over it:

```typescript
type EventMap = {
  [E in Event as E["type"]]: (event: E) => void;
};

/**
 * {
 *   click: (event: { type: "click"; x: number; y: number; }) => void;
 *   hover: (event: { type: "hover"; element: HTMLElement; }) => void;
 * }
 */
```


Mapped Types

`ComponentProps<T>` is a type helper in React that allows developers to extend third-party and DOM elements with additional props.

## Importing

You can either import it from `react` itself:

```tsx
import { ComponentProps } from "react";
```

Or, grab it off the `React` namespace itself.

```tsx
import React from "react";

type Example = React.ComponentProps<"div">;
```

## Use Cases

### Extending DOM Elements

```typescript
type ButtonProps = React.ComponentProps<"div">;
```

You can use `ComponentProps` to extend DOM elements. This is useful when creating custom components that inherit basic properties from native elements.

For instance:

```tsx
type CustomProps {
  text: string;
}

const Div = ({
  text,
  ...props
}: CustomProps &
  React.ComponentProps<"div">) => {
  // Access text here
  return <div {...props}></div>;
};
```

In this example, the CustomProps type defines a single custom prop, text. The `ComponentProps<T>` helper extends the props of the `div` element with any additional props passed to our custom `Div`.

An alternative approach is to use an interface to extend the native component:

```tsx
interface CustomProps
  extends React.ComponentProps<"div"> {
  text: string;
}

const Div = ({ text, ...props }: CustomProps) => {
  // Access text here
  return <div {...props}></div>;
};
```

In this approach, the CustomProps type extends the props of the `div` element, with the additional definition of a `text` prop. The spread operator passes all props, including the text prop, to the `Div` component.

### Extending Third-Party Components

Another use case for `ComponentProps<T>` is to extend third-party components with custom props. This can be useful when you need to extend a third-party component, but they don't expose the necessary types themselves.

```tsx
import ThirdPartyComponent from "third-party";

type CustomProps {
  foo: string;
  bar: number;
}

const MyComponent = ({
  foo,
  bar,
  ...props
}: CustomProps &
  React.ComponentProps<
    typeof ThirdPartyComponent
  >) => {
  // use foo and bar here as needed
  return <ThirdPartyComponent {...props} />;
};
```

In this example, the `CustomProps` type defines two custom props, `foo` and `bar`. The `ComponentProps<T>` helper grabs the props of the `ThirdPartyComponent` component, then we use the `&` intersection to add our `CustomProps`.

Of course, if the library _does_ expose the correct types, it's often worth using those instead:

```tsx
import ThirdPartyComponent, {
  ThirdPartyComponentProps,
} from "third-party";

type CustomProps {
  foo: string;
  bar: number;
}

const MyComponent = ({
  foo,
  bar,
  ...props
}: CustomProps &
  ThirdPartyComponentProps) => {
  return <ThirdPartyComponent {...props} />;
};
```

But in cases where they don't, `ComponentProps<T>` can be a useful escape hatch.

## ComponentPropsWithRef

If you need to also extract the type of the component's `ref`, you can use `React.ComponentPropsWithRef<T>`. For instance:

```tsx
// | ((instance: HTMLButtonElement | null) => void)
// | React.RefObject<HTMLButtonElement>
// | null
// | undefined
type ButtonRef =
  React.ComponentPropsWithRef<"button">["ref"];
```

This resolves into a pretty complicated type - but it represents anything that can be passed into a `<button>`'s ref.


React `ComponentProps<T>` Type Helper

A type helper is a type that can accept other types as arguments. It's like a function, but for types. `Record` is a great example:

```typescript
type MyObj = Record<string, string>;

const obj: MyObj = {};

obj.foo = "bar";

obj[1] = "baz"; // Error: Type 'number' is not assignable to type 'string'.
```

Here, we are defining a type `MyObj` that is an object with string keys and string values. We pass in the types `string` and `string` as arguments to the `Record` type helper, and it returns a new type we can use in our applications.

The syntax might look a bit unusual. But it's just like a function, only that it operates on types instead of values. Instead of `()`, we use `<>`.

## Built-In Utility Types

TypeScript comes with a number of built-in utility types that can be used to create and manipulate types. These are globally available throughout your project - no need to import them. Some of the most commonly used ones include:

- `Partial<T>`: Creates a type with all properties of another type set to optional.
- `Pick<T, K>`: Creates a new type by picking a set of properties `K` from another type `T`.
- `Required<T>`: Creates a type with all properties of another type set to required.
- `Readonly<T>`: Creates a type with all properties of another type set to readonly.

## Building Your Own Custom Type Helpers

You'll often need to build your own type helpers for your project. Let's imagine you have lots of values in your app that might be _something_ or `null` or `undefined`. You could keep writing `string` | `null` | `undefined` everywhere, but that would be tedious and error-prone. Instead, you can create a custom type helper:

```typescript
type Maybe<T> = T | null | undefined;
```

Here, we are defining a custom type helper `Maybe` that takes a type `T` as a parameter and returns a new type that can either be `T`, `null`, or `undefined`.

We can use it like so:

```typescript
interface User {
  id: string;
  name: string;
  phoneNumber: Maybe<string>;
}
```


Type Helpers

`@ts-expect-error` lets you specify that an error _will_ occur on the next line of the file.

Without `@ts-expect-error`, this line of code errors:

```typescript twoslash
// @errors: 2322
const x: string = 12;
```

But with it, it quietens the error:

```typescript twoslash
// @ts-expect-error
const x: string = 12;
```

## Fixing the 'Unused `@ts-expect-error` directive' error

In fact, if `@ts-expect-error` _doesn't_ find an error, it will source an error itself:

```typescript twoslash
// @errors: 2578
// @ts-expect-error
```

This is helpful because it lets us use `@ts-expect-error` to [test our types](/how-to-test-your-types) by letting us be _sure_ that an error will occur.

## Including a description with `@ts-expect-error`

You might also run into this error:

> "Include a description after the `@ts-expect-error` directive to explain why the `@ts-expect-error` is necessary. The description must be 3 characters or longer."

This comes from a [TypeScript ESLint rule](https://typescript-eslint.io/rules/ban-ts-comment). It exists to force you to _explain_ why you're using expecting an error.

Imagine a line of code like this:

```typescript twoslash
const expectsString = (x: string) => {};

// ---cut---

// @ts-expect-error
expectsString(123);
```

It's not clear why we're passing this piece of code a number. Is it a mistake? Is it intentional? If it's intentional, why?

Adding a description to the `@ts-expect-error` directive helps us explain why we're expecting an error:

```typescript twoslash
const expectsString = (x: string) => {};

// ---cut---

// @ts-expect-error: Should expect string
expectsString(123);
```

## Descriptions aren't perfect

Though it's important to note that description doesn't help TypeScript narrow what the error is at all. We might be generating an error we didn't expect, such as misspelling the function:

```typescript twoslash
const expectsstring = (x: string) => {};

// @errors: 2552
expectsString(123);
```

In fact, there's no native way in TypeScript that you can narrow down the exact error thrown by a line of code. So, using `@ts-expect-error` with a loose description is your best bet.

## `@ts-expect-error` or `@ts-ignore`?

When you actually want to ignore an error, you'll be tempted to use `@ts-ignore`. It works similarly to `@ts-expect-error`, except for one thing: it won't error if it _doesn't_ find an error:

```typescript twoslash
// @ts-ignore
const x: string = 12;
```

Sometimes, you'll want to ignore an error that later down the line gets fixed. If you're using `@ts-ignore`, it'll just ignore the fact that the error is gone.

But with `@ts-expect-error`, you'll actually get a hint that the directive is now safe to remove. So if you're choosing between them, pick `@ts-expect-error`.


How to use @ts-expect-error

In TypeScript, object types let you define the shape of an object. Alongside `string`, `number` and `boolean`, it's one of the most commonly used annotations in a TypeScript codebase. There are three main ways they're declared.

The first is to use the `interface` keyword:

```typescript
interface User {
  name: string;
  age: number;
  email: string;
}
```

In this example, `User` is an object type with three properties: `name`, `age`, and `email`. You can also define an object type inline:

```typescript
function printUser(user: {
  name: string;
  age: number;
  email: string;
}) {
  console.log(`Name: ${user.name}`);
  console.log(`Age: ${user.age}`);
  console.log(`Email: ${user.email}`);
}
```

In this example, the `printUser` function accepts an object with three properties: `name`, `age`, and `email`. This is equivalent to the `User` interface defined above.

You can also use the `type` keyword:

```typescript
type User = {
  name: string;
  age: number;
  email: string;
};
```

Defining object types will give you a few different kinds of safety. It'll prevent you from passing objects with incorrectly typed or missing properties:

```typescript
const printUser = (user: User) => {};

printUser({
  name: "John Doe",
  age: 42,
}); // Type error - email is missing!

printUser({
  name: "John Doe",
  age: "42",
  email: "john@doe.com",
}); // Type error - age is the wrong type!
```

It'll also give you type safety (and autocomplete!) when accessing properties on objects:

```typescript
const printUser = (user: User) => {
  user.doesNotExist; // doesNotExist is not a property on User!
};
```


Object Types

> Element implicitly has an 'any' type because expression of type 'X' can't be used to index type 'Y'.

This error is likely occurring because you're trying to use a type that's too loose to access an object's properties.

```typescript twoslash
// @errors: 7053
const myObj = {
  a: 1,
  b: 2,
};

const access = (str: string) => {
  return myObj[str];
};
```

## Solution 1: Tighten the index

One solution is to try to make the type doing the indexing tighter. In this case, by changing `str` to `keyof typeof myObj`:

```typescript twoslash
const myObj = {
  a: 1,
  b: 2,
};

// ---cut---
const access = (str: keyof typeof myObj) => {
  return myObj[str];
};
```

This is very safe because it ensures that the string you're using to index into the object is one of the keys of the object. But it's not always possible.

## Solution 2: Loosen the object type

When you declare an object, TypeScript will try to infer the most specific type possible. In this case, it's inferring that `myObj` is an object with two properties, `a` and `b`, whose values are numbers.

If you want to loosen the type of the object, you can do so by adding a type annotation:

```typescript twoslash
const myObj: Record<string, number> = {
  a: 1,
  b: 2,
};
```

Now, we can access the object with any string - and also add any string to the object:

```typescript twoslash
const myObj: Record<string, number> = {
  a: 1,
  b: 2,
};

// ---cut---

// We can add new keys to the object!
myObj["c"] = 3;

const access = (str: string) => {
  // Accessing with string is perfectly OK!
  return myObj[str];
};
```

Note that if you choose this approach, you should add [`noUncheckedIndexedAccess`](https://www.totaltypescript.com/tips/make-accessing-objects-safer-by-enabling-nouncheckedindexedaccess-in-tsconfig) to your tsconfig, which will give you extra safety when accessing the object.

## Solution 3: Cast the index

Finally, you can do a cast inside the access itself:

```typescript twoslash
const myObj = {
  a: 1,
  b: 2,
};

// ---cut---

const access = (str: string) => {
  return myObj[str as keyof typeof myObj];
};
```

This is slightly less safe and might result in an unexpected result because we're fooling TypeScript into thinking that `myObj[str]` will always return a `number`. But if we call `access` with `c`, we won't get a number back at runtime:

```typescript twoslash
const myObj = {
  a: 1,
  b: 2,
};

const access = (str: string) => {
  return myObj[str as keyof typeof myObj];
};

// ---cut---

/**
 * TS things it's a number, but it's actually undefined!
 */
const cResult = access("c");
//    ^?
```

If possible, you should be using solution 1 or 2 instead - but having this cast in your pocket can be useful.


Type string can't be used to index type X

In TypeScript, `PropertyKey` is a global type in TypeScript that represents the data type of a property key. It can be a `string`, a `symbol`, or a `number`.

You don't need to import it into your project - it's available globally.

```typescript
// string | number | symbol
type Example = PropertyKey;
```

This can be useful in a sticky situation where you want to create record types with all possible keys:

```typescript
type RecordWithAllKeys = Record<
  PropertyKey,
  unknown
>;
```


The `PropertyKey` Type

In TypeScript, literal types let you create types that express specific values.

For instance, let's say you only wanted to accept `success` or `failure` in a function argument. You could use `string`:

```typescript
function printStatus(status: string) {
  console.log(`Status is: ${status}`);
}

printStatus("error"); // No type error!
```

But as you can see, we can call `printStatus` with any `string` value, which is not what we want.

Instead, we can use a literal type:

```typescript
function printStatus(
  status: "success" | "failure"
) {
  console.log(`Status is: ${status}`);
}

printStatus("success"); // Outputs: Status is: success
printStatus("error"); // Type error!
```

Now, we can only call `printStatus` with the values `success` or `failure`.

We can also use literal types with other basic types:

```typescript
// Numeric literals
type ValidIndexes = 1 | 2 | 3 | 4 | 5;

// Boolean literals
type SuccessState = {
  success: true;
  data: string;
};

type FailureState = {
  success: false;
  error: string;
};
```

In the example above, `ValidIndexes` can only be `1`, `2`, `3`, `4`, or `5`. `SuccessState` can only be `{ success: true, data: string }`, and `FailureState` can only be `{ success: false, error: string }`.


Literal Types

The `any` type in TypeScript is a workaround for cases when you don't know what type a value might be. It allows you to assign a variable or function parameter to be of literally any type.

Here's an example of using `any` in a function argument:

```typescript
function greet(name: any) {
  console.log(`Hello, ${name}!`);
}

greet("John"); // Outputs: Hello, John!
greet(123); // Outputs: Hello, 123!
```

`any` lets you do extremely dangerous things in TypeScript. By marking a variable as `any`, you're telling the compiler to ignore any type errors that might occur.

```typescript
const user: any = {
  name: "John",
  age: 30,
};

user.roles.push("admin"); // Runtime error!
```

In the example above, we're trying to push a new value to the `roles` array, but the `roles` property doesn't exist on the `user` object. This will cause a runtime error, but TypeScript won't warn us about it because we've marked the `user` variable as `any`.

## `any` vs `unknown`

The `unknown` type is a type-safe counterpart of `any`, which requires you to perform a type check before using the variable. Unlike `any`, `unknown` can help prevent runtime errors by forcing you to narrow down the type of the variable before using it in your code.

Here's an example of using `unknown` in a function argument:

```typescript
function greet(name: unknown) {
  if (typeof name === "string") {
    console.log(`Hello, ${name}!`);
  }
}

greet("John"); // Outputs: Hello, John!
greet(123); // No output
```

Overall, the `any` type can be useful in situations where you need more flexibility, but it comes with the cost of losing type safety. It's best to use it sparingly and with caution.


The `any` type

In TypeScript, union types let you express types that could be one of several different things.

Here's an example of a union type in a function argument:

```typescript
function printId(id: string | number) {
  console.log(`ID is: ${id}`);
}

printId("abc"); // Outputs: ID is: abc
printId(123); // Outputs: ID is: 123
```

In the example above, the `id` parameter can be either a `string` or a `number`.

Union types can be used with any type, including literals:

```typescript
type Status = "success" | "failure";

function printStatus(status: Status) {
  console.log(`Status is: ${status}`);
}

printStatus("success"); // Outputs: Status is: success
printStatus("error"); // Type error!
```

As you can see, union types provide a level of type safety that `any` type lacks. It prevents errors at compile-time, reducing the chances of runtime issues.

You can include as many members as you want in a union type:

```typescript
type MassiveUnionType =
  | "animal"
  | {
      whatever: string;
    }
  | boolean
  | (() => void)
  | 100
  | "other string";
```

## Examples of Union Types

Here's a list of things you could use union types for in TypeScript:

```typescript
type HTTPRequestMethods =
  | "GET"
  | "POST"
  | "PUT"
  | "DELETE";
```

```typescript
type CSSLengthUnits =
  | "em"
  | "ex"
  | "ch"
  | "rem"
  | "vw"
  | "vh"
  | "vmin"
  | "vmax"
  | "px"
  | "cm"
  | "mm"
  | "in"
  | "pt"
  | "pc";
```

```typescript
type UserRoles =
  | "admin"
  | "editor"
  | "contributor"
  | "subscriber";
```

```typescript
type PaymentMethods =
  | "credit_card"
  | "debit_card"
  | "paypal"
  | "bank_transfer";
```

```typescript
type HTTPResponseStatusCodes =
  | 200
  | 201
  | 400
  | 401
  | 403
  | 404
  | 500;
```

```typescript
type NavigationalDirections =
  | "north"
  | "south"
  | "east"
  | "west";
```

```typescript
type SocialMediaButtonsIcons =
  | "facebook"
  | "twitter"
  | "instagram"
  | "pinterest"
  | "linkedin";
```

```typescript
type TimeZones =
  | "GMT"
  | "EST"
  | "CST"
  | "PST"
  | "JST"
  | "AEST"
  | "CET"
  | "EET"
  | "IST";
```


Global Scope

The Prettify Helper