Typescript tricks that you should know

Hello, I decided to write such article where we will analyze some typescript life hacks that beginners often don’t know about when learning, perhaps it will be useful even not only for beginners, maybe if you have been working with typescript for a long time, you will still highlight something new for yourself.

#Exhaustive Check in TypeScript

An exhaustive check in TypeScript ensures that all possible cases in a type or union are handled. It is commonly used when working with union types (especially discriminated unions) to verify that no cases are missed during runtime logic, such as in a switch statement or conditional branches.

Let’s start with a script to demonstrate how this works. Imagine we have a union type that represents CarBrands, including BMW and Mercedes. Then, we define a basic CarBase interface containing general information about a car, such as its year of manufacture and brand. From this base interface, we derive specific interfaces for different car models, each with its own unique fields.

We’ll also create another union type called Car that combines BMW and Mercedes. Essentially, this type acts as a “parent” type that encompasses all cars. Now, we want to create a function that accepts any car and performs actions based on its brand. This scenario is a classic use case for union types.

1type CarBrand = "BMW" | "Mercedes";
2
3interface CarBase {
4   year: number;
5   enginePower: number;
6   brand: CarBrand
7}
8
9interface Mercedes extends CarBase {
10   navigator: boolean;
11   brand: "Mercedes"
12}
13
14interface BMW extends CarBase {
15   security: boolean;
16   brand: "BMW"; 
17}
18
19type Car = Mercedes | BMW;
20
21function doSomethingWithCar( car: Car ) {
22   switch (car.brand){
23
24       case "BMW":
25           console.log("do something with BMW");
26       break;
27
28       case "Mercedes":
29           console.log("do something with Mercedes");
30       break;
31
32       default: 
33           console.log(car);
34   }
35}
36

In this example, the default case on line 33 will receive a never type. This means TypeScript recognizes that all possible cases in the union have been handled. Therefore, the default block will never execute.

The Problem With Extending a Union Type

Now let's imagine that someone in our team added a new type of car, let's say it will be Ford. They create the corresponding interface, include all necessary fields, and add it to the Car union type. However, TypeScript won’t warn you about this addition, and your function will fall into the default block. Please note that typescript at this stage, will not react in any way to the addition of a new type. Here in the default case, we kind of see that we have Ford type as well instead of never. Having fallen into this default case, we may have some kind of unforeseen behavior.

Solution: Adding an Exhaustive Check

Now we would like to clearly highlight such places so that when adding a new type, we do not forget to add something to them and in this case we can use this trick: To address this, we can use an exhaustiveCheck. This involves creating a function that accepts only the never type. By calling this function in the default block, TypeScript will throw an error if the union type is extended without updating the switch cases.

1type CarBrand = "BMW" | "Mercedes" | "Ford";
2
3interface CarBase {
4    year: number;
5    enginePower: number;
6    brand: CarBrand
7}
8
9interface Mercedes extends CarBase {
10    navigator: boolean;
11    brand: "Mercedes"
12}
13
14interface BMW extends CarBase {
15    security: boolean;
16    brand: "BMW"; 
17}
18
19interface Ford extends CarBase {
20    cruise: boolean;
21    brand: "Ford"; 
22}
23
24type Car = Mercedes | BMW | Ford;
25
26function exhaustiveCheck( param: never) {
27    console.log(`Case is not covered : ${param}`);
28}
29
30function doSomethingWithCar(car: Car) {
31    switch (car.brand){
32
33        case "BMW":
34            console.log("do something with BMW");
35        break;
36
37        case "Mercedes":
38            console.log("do something with Mercedes");
39        break;
40
41        default: 
42            exhaustiveCheck(car);
43    }
44}
45

If we extend the Car type by adding Ford but forget to include a case for it in the switch statement, TypeScript will throw an error. For instance, on line 42, you’ll see an error message like this: : Argument of type 'Ford' is not assignable to parameter of type 'never'.(2345)

This alerts us to handle the new type in the switch statement. Once we add a case for Ford, the error will disappear.

Conclusion

Exhaustive checks are a simple yet powerful technique to catch unhandled cases in your TypeScript code. They enhance type safety, reduce runtime bugs, and ensure your logic stays aligned with your types. If you’re working with union types, this approach is highly recommended.

#Typeguard with help of "is"

Sometimes, we need to check if a given Car object belongs to a specific type or model, such as identifying whether it is a BMWX6. Initially, this can be done within an if statement. TypeScript correctly infers the type within the if block, allowing access to type-specific fields.

1type CarBrand = "BMW" | "Mercedes";
2
3interface CarBase {
4 year: number;
5 brand: CarBrand
6}
7
8interface Mercedes extends CarBase {
9    navigator: boolean;
10    brand: "Mercedes"
11}
12
13interface BMWBase extends CarBase {
14    security: boolean;
15    brand: "BMW"; 
16}
17
18interface BMWX6 extends BMWBase {
19    model: "X6",
20    xseries: boolean;
21}
22
23interface BMWX7 extends BMWBase {
24    model: "X7",
25    xseries: boolean;
26}
27
28type BMW = BMWX6 | BMWX7;
29
30type Car = Mercedes | BMW;
31
32function doSomethingWithCar(car: Car) {
33    // We need to do something with BMW x6 model
34    if(car.brand === "BMW" && car.model === "X6"){
35        // Here the xseries param that spesipic for X6 would be reachable and work fine with TypeScript
36        console.log(car.xseries);
37    }
38}
39

In this example, TypeScript recognizes the type of car within the if block and provides access to the xseries field. However, this approach mixes logic within the function, which is not ideal for maintainability. Extracting this logic into a separate function leads to an issue.

Extracted Logic Without Type Guard

When we extract the type-checking logic into another function, TypeScript no longer infers the type correctly, leading to an error:

1
2const isCarBMW6  = ( car: Car ) => {
3    return car.brand === "BMW" && car.model === "X6";
4}
5function doSomethingWithCar(car: Car) {
6    if( isCarBMW6(car)) {
7        // Here now TypeScript wouldnt be able identify car type correctly
8        console.log(car.xseries);
9    }
10}
11

When we did this on line 8 Typescript now woudlnt be able identify type of car and it would throw an error something like this: Property 'xseries' does not exist on type 'Car'. Property 'xseries' does not exist on type 'Mercedes'.(2339)

We can fix this issue by using a custom type guard with the is keyword. This explicitly tells TypeScript that the isCarBMW6 function narrows down the type of the object to BMWX6.

1type CarBrand = "BMW" | "Mercedes";
2
3interface CarBase {
4 year: number;
5 brand: CarBrand
6}
7
8interface Mercedes extends CarBase {
9    navigator: boolean;
10    brand: "Mercedes"
11}
12
13interface BMWBase extends CarBase {
14    security: boolean;
15    brand: "BMW"; 
16}
17
18interface BMWX6 extends BMWBase {
19    model: "X6",
20    xseries: boolean;
21}
22
23interface BMWX7 extends BMWBase {
24    model: "X7",
25    xseries: boolean;
26}
27
28type BMW = BMWX6 | BMWX7;
29
30type Car = Mercedes | BMW;
31
32const isCarBMW6  = ( car: Car ): car is  BMWX6 => {
33    return car.brand === "BMW" && car.model === "X6";
34}
35
36function doSomethingWithCar(car: Car) {
37    // We need to do something with BMW x6 model
38    if( isCarBMW6(car)) {
39        // Here the xseries param that spesipic for X6 would be reachable and work fine with TypeScript
40        console.log(car.xseries);
41    }
42}
43
44

Using this approach, TypeScript understands that within the if block, the car variable is of type BMWX6.

#Conditional Types

Conditional types are one of TypeScript’s most powerful and flexible features, allowing you to write types that dynamically adapt based on conditions. They enable you to perform type-level logic and create reusable, expressive type definitions that can handle complex scenarios.

At its core, a conditional type follows this structure:

1type Condition<T> = T extends string ? number : boolean;
2

This can be read as: “ If T extends String , then type would be Number ; otherwise, resolve to type Boolean. ”

Think of it as an if-else statement but at the type level. This feature allows developers to write more flexible type definitions that adapt to various inputs. Let’s see how conditional types can help us in a practical situation. Consider a scenario where we want to return different types of objects based on the input argument.

1type Bird = { flies: boolean };
2type Fish = { swims: boolean };
3type BirdOrFish<T> = T extends string ? Bird : Fish;
4
5function createAnimal<T>(arg: T): BirdOrFish<T> {
6  // Minimal logic to simulate the response based on the argument type
7  if (typeof arg === "string") {
8    return { flies: true } as BirdOrFish<T>;
9  }
10  return { swims: true } as BirdOrFish<T>;
11}
12
13const animal = createAnimal("sparrow");
14// TypeScript infers 'animal' as a 'Bird' type, so we can access its properties safely
15console.log(animal.flies); // true
16
17const animal2 = createAnimal(123);
18
19// TypeScript infers 'animal2' as a 'Fish' type
20console.log(animal2.swims); // true
21

Explanation

• Conditional Type Definition : BirdOrFish dynamically evaluates the type of T. If T is a string, it resolves to Bird otherwise, it resolves to Fish.
• Type Safety in Function Logic : TypeScript automatically infers the return type of createAnimal based on the argument provided (string or number).
• Dynamic Type Inference : When createAnimal("sparrow") is called, T extends string, so the return type is Bird. TypeScript allows safe access to the flies property. In second call when createAnimal(123) is called, T does not extend string, so the return type is Fish, and you can access swims.

By incorporating conditional types into your workflow, you can make your TypeScript code more expressive, robust, and maintainable. Experiment with them, and you’ll see just how powerful they can be for solving complex type challenges. Most of the built in TypeScript Utility types had been created by using conditional types. Here are few of them:

1// Exclude Utility Type
2type MyExclude<T, U> = T extends U ? never : T;
3
4type WithoutA = MyExclude<'a' | 'b' | 'c', 'a'>; // 'b' | 'c'
5type WithoutNumber = MyExclude<string | number | boolean, number>; // string | boolean
6
7// Extract Utility Type
8type MyExtract<T, U> = T extends U ? T : never;
9
10type OnlyA = MyExtract<'a' | 'b' | 'c', 'a'>; // 'a'
11type OnlyNumber = MyExtract<string | number | boolean, number>; // number
12
13
14// NonNullable Utility Type
15type MyNonNullable<T> = T extends null | undefined ? never : T;
16
17type CleanedType = MyNonNullable<string | number | null | undefined>; // string | number
18
19// Parameters Utility Type
20type MyParameters<T> = T extends (...args: infer P) => any ? P : never;
21
22type Fn = (arg1: string, arg2: number) => void;
23type FnParams = MyParameters<Fn>; // [string, number]
24

In examples you can see I had used something new in MyParameters type called infer. Dont be confused. In TypeScript, infer is a keyword used in conditional types to introduce a new type variable that represents part of a type being checked. It allows you to extract and work with specific parts of a type dynamically.

Basic Example:

1type Flatten<T> = T extends Array<infer Item> ? Item : T;
2

Here, we used the infer keyword to declaratively introduce a new generic type variable named Item instead of specifying how to retrieve the element type of T within the true branch. This frees us from having to think about how to dig through and probing apart the structure of the types we’re interested in.

#Generic Types in React Component

Many of you are likely familiar with generics and how they work. However, in my experience, I’ve often seen developers run into issues where they solve type problems using type coercion or type casting. This approach goes against the very purpose of using TypeScript, which is to ensure type safety and prevent potential runtime errors. Often, these issues can be resolved more elegantly by using generics.

Here’s a real-life example of a reusable Select component in React. In the initial implementation, the lack of proper generics led to problems that developers worked around using type coercion.

1import { ChangeEvent, useMemo, useState } from "react";
2
3enum UserRole {
4  ADMIN = "ADMIN",
5  CONSUMER = "CONSUMER",
6  MODERATOR = "MODERATOR",
7}
8
9type SelectOptions = {
10  name: string;
11  value: UserRole;
12};
13
14interface SelectProps extends Omit<React.SelectHTMLAttributes<HTMLSelectElement>, 'onChange'> {
15  options: SelectOptions[];
16  value: string;
17  onChange: (value: string) => void;
18}
19
20export const Select = ({ onChange, options, value, ...rest }: SelectProps) => {
21  const onChangeHandler = (e: ChangeEvent<HTMLSelectElement>) => {
22    const value = e.target.value;
23    if (value) {
24      onChange(value);
25    }
26  };
27
28  const optionsList = useMemo(
29    () =>
30      options.map((option) => (
31        <option value={option.value} key={option.value}>
32          {option.name}
33        </option>
34      )),
35    [options]
36  );
37
38  return (
39    <select {...rest} value={value} onChange={onChangeHandler}>
40      {optionsList}
41    </select>
42  );
43};
44
45const options: SelectOptions[] = [
46  {
47    name: "Admins role",
48    value: UserRole.ADMIN,
49  },
50  {
51    name: "Consumer role",
52    value: UserRole.CONSUMER,
53  },
54];
55
56const App = () => {
57  const [role, setRole] = useState<UserRole>(UserRole.ADMIN);
58
59  const onChange = (value: string) => {
60    setRole(value as unknown as UserRole);
61  };
62
63  return (
64    <Select
65      value={role as unknown as string}
66      onChange={onChange}
67      options={options}
68      disabled
69      required
70    />
71  );
72};
73
74export default App;
75

In the above example, the developer used type casting in lines 60 and 65 to coerce the types of value and onChange. This happened because the Select component was not designed to use generics, which meant the types for value and onChange were fixed and did not adapt to the specific use case.

Problems With This Approach:

• Type Inconsistencies : If someone added an option to the options array that didn’t align with the UserRole enum, TypeScript wouldn’t catch the error.
  const options = [ { name: "Invalid Role", value: "INVALID" }, // No type error here! ];
• Incorrect Data Handling : If the onChangeHandler function passed more than just value (e.g., an object containing additional data), the type would fail to account for it, leading to runtime issues.

These issues can be easily avoided by refactoring the component to use generics.

The Solution: Using Generics in the Select Component

Refactoring the Select component to use generics ensures type safety and reusability. Let’s look at the improved implementation:

1import { ChangeEvent, useMemo, useState } from "react";
2
3enum UserRole {
4  ADMIN = "ADMIN",
5  CONSUMER = "CONSUMER",
6  MODERATOR = "MODERATOR",
7}
8
9type SelectOptions<T> = {
10  name: string;
11  value: T;
12};
13
14interface SelectProps<T> extends Omit<React.SelectHTMLAttributes<HTMLSelectElement>, "onChange" | "value" > {
15  options: SelectOptions<T>[];
16  value: T;
17  onChange: (value: T) => void;
18}
19
20export const Select = <T extends string>({
21  onChange,
22  options,
23  value,
24  ...rest
25}: SelectProps<T>) => {
26  const onChangeHandler = (e: ChangeEvent<HTMLSelectElement>) => {
27    // Here using "as" does not beark an concept of typescript
28    const value = e.target.value as T;
29    if (value) {
30      onChange(value);
31    }
32  };
33
34  const optionsList = useMemo(
35    () =>
36      options.map((option) => (
37        <option value={option.value} key={option.value}>
38          {option.name}
39        </option>
40      )),
41    [options]
42  );
43
44  return (
45    <select {...rest} value={value} onChange={onChangeHandler}>
46      {optionsList}
47    </select>
48  );
49};
50
51const options: SelectOptions<UserRole>[] = [
52  {
53    name: "Admins role",
54    value: UserRole.ADMIN,
55  },
56  {
57    name: "Consumer role",
58    value: UserRole.CONSUMER,
59  },
60];
61
62const App = () => {
63  const [role, setRole] = useState<UserRole>(UserRole.ADMIN);
64
65  const onChange = (value: UserRole) => {
66    setRole(value);
67  };
68
69  return (
70    <Select<UserRole>
71      value={role}
72      onChange={onChange}
73      options={options}
74      disabled
75      required
76    />
77  );
78};
79
80export default App;
81

What Changed:

• Generic Parameter T : We introduced a generic parameter T for the Select component. This allows the component to adapt its types (value, onChange, and options) dynamically based on the data passed in.
• Dynamic Types : The value and onChange props now use T instead of fixed types like string. This ensures the Select component works seamlessly with any data type, such as enums or specific strings.
• Safe Type Assertions : In the onChangeHandler, we use as T to cast the e.target.value to the generic type. This is safe because TypeScript infers T from the props at runtime.
• Type-Safe Options : The options array now has type safety. TypeScript ensures all values align with T.
• Passing Generics Explicitly : At line 70, we explicitly pass the generic type UserRole to the Select component. This ensures that TypeScript knows T is UserRole and adjusts the types for value, onChange, and options accordingly.

By using generics, we’ve made the Select component more robust, reusable, and type-safe. This approach avoids issues caused by type coercion and ensures the integrity of the data throughout the application. Let me know if you’d like further refinements or additional examples!