DEV Community: Andrei Kondratev

Useful types: Build a route tree with TypeScript

Andrei Kondratev — Tue, 21 Jun 2022 08:40:08 +0000

Hello there!

In my previous article I wrote how to extract the type of route's params. Look there if you haven't seen it yet. Now I'm going to describe how I create route definitions in my project.

First of all, let's define some terms that will be used next. react-router-dom@6 allows to use nested routes, so we can define something like this

<Route path="/">
  <Route path="card" element={...}>
    <Route path=":cardId" element={...}>
      {...}
    </Route>
  </Route>
</Route>

In the code above /, card and :cardId are destructed segments of some path. If we join them, we get /card/:cardId. So let's call one of such segments a path and joined segments from some root to each specified path a fullPath.

OK, we need to use a path for some cases and a fullPath for another. And in my mind all data about every single route definition must be stored in one place. Moreover, this definition may have other information about the route, for instance, page title, default query-params, some flags or so on. And, of cause, I want to define route definitions as a tree because of the code above.

Briefly my ideal route definition:

can be built as a tree
stores all necessary data in the each node
automatically infers strong types (yes it's necessary)
is an once-declared structure that's shared throughout the application

First of all, let's see how to make a strongly typed tree. We can use an intersection of object types and generics for this. Let's define a type

type SomeData<Other> = {
  path: string;
} & Other;

So, SomeData defines the path property and also other properties from Other.

const q1: SomeData<{}> = {path: ""}
let q2: SomeData<{a: number}> = {path: "", a: 10}
let q3: SomeData<{nested: SomeData<{}>}> = {
  path: "",
  nested: {path: ""}
}

This solution allows to define a tree-like type of our routing definition, but it requires to write types manually. So we can declare some function that creates the definition object and automatically infers its type.

type RouteDefinition<Nested> = {
  path: string;
} & Nested;

function route<Nested>(
  path: string,
  nested: Nested
): RouteDefinition<Nested> {
  return {
    path,
    ...nested,
  }
}

In this case we can use the function route to create one routing definition node and then reuse the function for nested definitions

const q1 = route("card", {}); // {path: "card"}
const q2 = route("card", {
  a: route("a", {})
}); // {path: "card", a: {path: "a"}}

Maybe now it looks like something not very convenient, but we'll return to this in the future.

What about the full path property? We define one part of the full path inside the definition node and all nested definitions must contain this prefix in their full path. I suggest to change the nested object to the function that takes as the first parameter the full path for all nested routes and returns the nested route definitions.

First of all, we'll add the fullPath property to the RouteDefinition type

type RouteDefinition<Nested> = {
  path: string;
  fullPath: string;
} & Nested;

Then we'll need to add the prefix parameter to the route function that it'll be possible to define the node with the nested full path. We'll also change the nested object to the createNested function that's been described above. Let's make it optional for a more convenient use.

function route<Nested>(
  path: string,
  prefix: string,
  createNested?: (fullPath: string) => Nested,
): RouteDefinition<Nested> {
  const fullPath = `${prefix}/${path}`
  const nested = createNested 
    ? createNested(fullPath) 
    : ({} as Nested);

  return {
    path,
    fullPath,
    ...nested,
  }
}

And now we can use this function for defining nested routes like this

const q1 = route("card", ""); // {path: "card", fullPath: "/card"}

const q2 = route("card", "", prefix => ({
  a: route("a", prefix),
  b: route("b", prefix, prefix => ({
    c: route("c", prefix)
  }))
})); 
/**
  {
    path: "card",
    fullPath: "/card",
    a: {
      path: "a",
      fullPath: "/card/a"
    },
    b: {
      path: "b",
      fullPath: "/card/b",
      c: {
        path: "c",
        fullPath: "/card/b/c"
      }
    }
  }
 */

We can create all route definitions as an object and share it throughout our application. You also can append another properties like title, isModal, etc to the node definition. Moreover, such approach can be used not only to create a route tree, but also to create any tree-like structures.

In the next article I would like to describe how to work with parameters in the url and build properties in the route definition that depend on the url parameter. Follow me and see you in the next article.

Useful types: Extract route params with TypeScript

Andrei Kondratev — Mon, 02 May 2022 21:57:09 +0000

Recently, I started working on a new project with React and TypeScript. I used react-router-dom@6 for routing and a few of my routes look like this

/card
/card/:cardId
/card/:cardId/transaction
/card/:cardId/transaction/:transactionId
// ... and so on

So, I really love TypeScript and always try to create strong typed system especially if types will be inferred automatically. I tried to define a type that would infer a route's parameters type using the path. This is a story about how to do it.

As you know TypeScript has conditional types and template literal types. TypeScript also allows to use generics with all of these types. Using conditional types and generics you can write something like this

type ExtractParams<Path> = Path extends "card/:cardId" 
   ? { cardId: string }
   : {}

type Foo1 = ExtractParams<"card"> // {}
type Foo2 = ExtractParams<"card/:cardId"> // {cardId: string}

Inside a conditional type we can use a template literal type to discover a parameter in the path. Then we can use an infer keyword to store an inferred type to a new type parameter and use the parameter as a result of the conditional type. Look at this

type ExtractParams<Path> = Path extends `:${infer Param}`
   ? Record<Param, string>
   : {}

type Bar1 = ExtractParams<"card"> // {}
type Bar2 = ExtractParams<":cardId"> // {cardId: string}
type Bar3 = ExtractParams<":transactionId"> // {transactionId: string}

It's OK, but what about more complex path? We can also use the infer and template types to split the path into segments. The main idea of the extracting type is to split off one segment, try to extract a parameter from this segment and reuse the type with the rest of the path recursively.
It may be implemented like this

type ExtractParams<Path> = Path extends `${infer Segment}/${infer Rest}`
  ? Segment extends `:${infer Param}` ? Record<Param, string> & ExtractParams<Rest> : ExtractParams<Rest>
  : Path extends `:${infer Param}` ? Record<Param, string> : {}

type Baz1 = ExtractParams<"card"> // {}
type Baz2 = ExtractParams<"card/:cardId"> // {cardId: string}
type Baz3 = ExtractParams<"card/:cardId/transaction"> // {cardId: string}
type Baz4 = ExtractParams<"card/:cardId/transaction/:transactionId"> // {cardId: string, transactionId: string}

But in this case, if the path can't be splitted by segments we have to try to extract the parameter from Path because it may be the last segment of a complex path that can contain some parameter. So, we have a duplicated path extracting logic. I suggest separating this logic into another type. My finally solution is

type ExtractParam<Path, NextPart> = Path extends `:${infer Param}` ? Record<Param, string> & NextPart : NextPart;

type ExtractParams<Path> = Path extends `${infer Segment}/${infer Rest}`
  ? ExtractParam<Segment, ExtractParams<Rest>>
  : ExtractParam<Path, {}>

const foo: ExtractParams<"card"> = {};
const bar: ExtractParams<"card/:cardId"> = {cardId: "some id"};
const baz: ExtractParams<"card/:cardId/transaction/:transactionId"> = {cardId: "some id", transactionId: "another id"}


//@ts-expect-error
const wrongBar: ExtractParams<"card/:cardId"> = {};
//@ts-expect-error
const wrongBaz: ExtractParams<"card/:cardId/transaction/:transactionId"> = {cardId: "some id"};

I use a special type parameter NextPart to determine what it has to do after extracting - try to extract parameters from the rest of the path or stop recursion.

I hope this story's been useful for you, you've learned something new. Maybe now you can improve something in your project.

Later I'm going to write a story about how I've implemented a route tree with the extracting parameters type and how I've used that with React and react-router-dom. Thanks

TypeScript: Type-based binary adder

Andrei Kondratev — Sat, 13 Mar 2021 09:58:57 +0000

Everything described in the article is relevant for the 4.2.3 version of TypeScript.

Hi there!
The TypeScript now supports Variadic Tuple Types. It's mean that we can use spread operator and generic parameters to create types that contvert on array-like type to another. For example, let's create a type that appends an element to an array.

type Append<T extends unknown[], R> = [R, ...T];

let a1: Append<[1, 2, 3], 0>;
//   ^ = let a1: [0, 1, 2, 3]
let a2: Append<[], "some">;
//   ^ = let a2: ["some"]
let a3: Append<[1, "q", false], {a: number}>;
//   ^ = let a3: [{a: number}, 1, "q", false]

playground

OK, but what if we want to create a type that will remove the first element of the array. This type isn't that simple because an empty array [] extends unknown[] and we have to check that there are elements in the original array. We can do this using conditional type and type inference

type Slice<T extends unknown[]> = T extends [infer _, ...infer Tail] 
  ? Tail 
  : [];

let b1: Slice<[1, 2, 3]>;
//   ^ = let b1: [2, 3]

let b2: Slice<[1]>;
//   ^ = let b2: [];

let b3: Slice<[]>;
//   ^ = let b3: [];

playground

Let's complicate the task. How to create a type that will reverse an array? In typical situation we would use loops or recursion to iterate the array. In Typescript types we can use recursive type alias.

type Reverse<T extends unknown[]> =
T extends [infer Item, ...infer Tail] 
  ? [...Reverse<Tail>, Item] 
  : [];

let c1: Reverse<[1, 2, 3]>;
//   ^ = let c1: [3, 2, 1]

let c2: Reverse<[1]>;
//   ^ = let c2: [1]

let c3: Reverse<[]>;
//   ^ = let c3: []

playground

There is one unpleasant moment with this approach - typescript doesn't use generics' constraints to define the inference types. If we have type Some<T extends number> = T we can't use infer defined type as T parameter.

type Some<A extends number> = A;

type Some2<A extends number[]> = A extends Array<infer B> 
  ? Some<B> 
//       ^ Error: Type 'B' does not satisfy the constraint 'number'
  : number;

But if we change Some type to type Some<T> = T extends number ? T : number, we can use infered type. These two vertion of Some type are not equal, but sometimes this approach can be used.

Type-based binary adder

Ok, now we know everything to create a binary adder. If we don't know what a binary adder is, you can learn it yourself. Firstly, we create several logical operations.

type Xor<A, B> = A extends B ? 0 : 1;
/*
  A  B  Xor<A, B>
  0  0  0
  1  0  1
  0  1  1
  1  1  0
*/

type And<A, B> = A extends 1 ? B extends 1 ? 1 : 0 : 0;
/*
  A  B  And<A, B>
  0  0  0
  1  0  0
  0  1  0
  1  1  1
*/

type Or<A, B> = A extends 1 ? 1 : B extends 1 ? 1 : 0;
/*
  A  B  Or<A, B>
  0  0  0
  1  0  1
  0  1  0
  1  1  1
*/

Secondly, consider the adder circuit.

As you can see we have to use 2 bits of 2 numbers and carry-in and return result bit and carry-out.

type Sum<A, B, CIn> = Xor<Xor<A, B>, CIn>;
type COut<A, B, CIn> = Or<And<A, B>, And<Xor<A, B>, CIn>>;

Finally, we create the adder type.

type Add<A, B, CIn = 0> = 
  A extends [...infer AN, infer AC] 
    ? B extends [...infer BN, infer BC]
      ? [...Add<AN, BN, COut<AC, BC, CIn>>, Sum<AC, BC, CIn>]
      : []
    : [];

let d1: Add<[0], [1]>
//   ^ = let d1: [1]

let d2: Add<[0, 1], [0, 1]>
//   ^ = let d2: [1, 0]

let d3: Add<[0, 1, 1, 1], [0, 0, 0, 1]>
//   ^ = let d3: [1, 0, 0, 0]

let d4: Add<[1, 1, 1, 1], [0, 0, 0, 1]>
//   ^ = let d4: [0, 0, 0, 0]

playground

Other binary operations can be implemented using these principles. Will such types be needed in real projects? I don’t think so. But I think these principles will help you create really useful types. Subscribe to me and I will try to tell you more about interesting types of TypeScript.

React Batch Mount

Andrei Kondratev — Tue, 02 Mar 2021 05:47:42 +0000

Hey there!
In the Wild Internet there are many different articles about increase performance of React applications. But mainly these articles describe how to reduce the number of component rerenders. What if the application takes a long time to mount components?

Let's describe the problem. Your user wants to see a list of some items (for example, musics, messages, transactions, etc). This list may contain thousands of items, and each item is mounted complex component with calculations effects and even explicit manipulation of the children. Obviously, mounting all components for all items at once is a very bad idea and no on does that.

What is usually done in this case? In this case, a tichnique is used that allows you not render components for all data. These are techniques such as pagination, lazy loading, virtualization and so on. But what if the list of items in the user interface is represented by a form with thousands of inputs? In some cases, you can any of the previous techniques, but in other cases you must render all components for correct form work and a good UX.

One solution to this problem is not to mount all the components at once, but in small parts. In this case, the user will have to wait until all the components are mounted, but the browser will have time to print frames and the user will see the dynamic loading and even interact with loaded part.

`React.Suspense` and `React.lazy`

How to implement this idea? The straightforward way is use the component that has some state and provides the knowledge which children components are mounted. This can lead to problems with extra renders, complex memoization and so on.

From React 16.6, you can use React.Suspense and React.lazy for rendering components in the dynamic loaded modules. lazy returns a special component that is specially mounted and processed in the React tree. The dynamic import returns a promise that is wrapped in the Lazy component. When the promise is fulfilled, the Lazy component is pointwise updated without triggering an update to its ancestors. We can replace the dynamic import promise to a promise that we control and mount content of Lazy component when we want.

// The simple react component
const Some = () => <div>It's lazy wrapped component</div>;

// Create a promise that is resolved by a object that
// looks like a dynamic import object
const promise = Promise.resolve({default: Some});

// Wrap the promise the lazy function
const LazyWrapped = lazy(() => promise);

Now we can try to mount LazyWrapped component to React tree and get an error

A React component suspended while rendering, but no fallback UI was specified.

The Lazy component requires React.Suspense to be among its ancestors. These components is completely controlled by React.

const App = () => (
  <Suspense fallback="Loading ...">
    {Array.from({ length: 100 }).map((_, i) => (
      <LazyWrapped key={i} />
    ))}
  </Suspense>
);

Demo

What about the rerenders of these components? Let's add console.log to several components.

// HOC create component that close n
const Some = (n) => () => {
  console.log("render Some", n);
  return <div>It's lazy wrapped component</div>;
};

const LazyWrapped1 = lazy(
  () =>
    new Promise((resolve) => {
      setTimeout(() => {
        console.log("promise 1 resolved");
        resolve({ default: Some(1) });
      }, 300);
    })
);

const LazyWrapped2 = lazy(
  () =>
    new Promise((resolve) => {
      setTimeout(() => {
        console.log("promise 2 resolved");
        resolve({ default: Some(2) });
      }, 500);
    })
);

const App = () => {
  console.log("render App");
  return (
    <Suspense fallback="Loading ...">
      <LazyWrapped1 />
      <LazyWrapped2 />
    </Suspense>
  );
};

Now we have only two Lazy component, but theirs promises are fulfilled at different times. When the root component and the lazy components are rerender, they print to the console about it. And the promises print too when its are resolved. Let's take a look at the console.

render App 
promise 1 resolved 
render Some 1
promise 2 resolved 
render Some 2

Demo

How you can see when the promises are fulfilled only the Lazy component rerenders. Therefore we can create some mechanism that controls promises fulfilled. It'll allow to control mount of the components without rerendering other parts of the application.

react-batch-mount

I try to implement its mechanism in react-batch-mount library.
The main part is hidded inside the library and name scheduler. The scheduler has queue of the promises resolve functions. If the queue isn't empty the scheduler plans the next batch mount via requestAnimationFrame.

To connect a component to batch rendering, you can use the HOC batchMount.

const Some = batchMount(() => {
  return <div>It's batched component</div>;
});

batchMount internally creates a promise which will be resolved by the scheduler. This promise is wrapped in React.lazy and the Lazy component is returns by batchMount. We can use Some component inside Suspense in our App.

const App = () => {
  return (
    <div>
      <Suspense fallback={<div>Loading ... </div>}>
        {Array.from({ length: 50 }).map((_, i) => (
          <Some key={i} />
        ))}
      </Suspense>
    </div>
  );
};

Demo in TypeScript

You can pass options to batchMount at the second parameter. One of the options if fallback. If fallback is passed batchMount wrap the Lazy component to Suspense with the passed fallback. This will create Suspense to each item.

const Some = batchMount(
  () => {
    return <div>It's batched component</div>;
  },
  {
    fallback: <div>Loading</div>
  }
);

Demo

By default the scheduler mounts component at a time. You can configure its behavior using the setGlobalConfig function. This function takes either {batchSize: number} or {budget: number}. If you explicitly specify the batch size, the scheduler will fill the batch of the specified size if there are enough components. budget is the time in milliseconds that the scheduler should try to spend on mounting the batch. When the previous batch is fully mounted, the scheduler will calculate the size of the next batch based on the mount time of the previous and specified budget.

To see the full power of the budget, let's try to simulate a long component mounting.

const useHighload = (ms) => {
  const mounted = useRef(false);
  if (!mounted.current) {
    mounted.current = true;

    const start = Date.now();
    let now = Date.now();
    while (now - start < ms) {
      now = Date.now();
    }
  }
};

const Some = batchMount(
  () => {
    useHighload(100);
    return <div>It's batched component</div>;
  },
  {
    fallback: <div>Loading</div>
  }
);

setGlobalConfig({budget: 500});

Demo

What's next

Now you know a new approach to optimizing a React application and several internal features of React. You can look at the rest of react-batch-mount features, experiment with it, maybe even use it in your application.

DEV Community: Andrei Kondratev

Useful types: Build a route tree with TypeScript

Useful types: Extract route params with TypeScript

TypeScript: Type-based binary adder

Type-based binary adder

React Batch Mount

React.Suspense and React.lazy

react-batch-mount

What's next

`React.Suspense` and `React.lazy`