DEV Community: Gleb Irovich

Application State Management

Gleb Irovich — Thu, 11 Mar 2021 21:17:20 +0000

Welcome, everyone! In today's post, I would like to talk about the application state management. We will discuss what the state is and build a bare-bone state management solution with Typescript.

What is the state and why we need it?

Application state is a piece of information held together and can be accessed from different parts of your application. Data stored in the state is a snapshot of your program's dynamic properties in a given moment.
Why do we need it?

State helps to keep pieces of application in sync
Centralization makes an application more maintainable and the code more readable

Simple state

In an extremely simplified version, a state is just a JavaScript object. The state has some properties that different consumers can access. In the example below, our state keeps track of the count. stateConsumerA mutates the state by incrementing the count, while stateConsumerB logs state to the console.

interface State {
  count: number;
}

const state: State = {
  count: 0
};

function stateConsumerA() {
  state.count++;
}

function stateConsumerB() {
  console.log(state);
}

stateConsumerA();
stateConsumerB(); // log: {count: 1}

What can we do better? One of the important requirements for the state is immutability. Immutability helps to prevent some undesired side-effects, which the mutation can cause. Moreover, immutability allows comparing different state snapshots to decide if an expensive operation should be performed.

Immutable state

Imagine your application being a public library and your state being a sacred book. As a library, you are willing to share this book's content, but you don't want it to be damaged. Therefore when someone requests that book, you send this person a copy.
Immutability in JavaScript is also achieved by creating a copy.

Consider an example below. We use an IIFE to encapsulate the application state in the closure and expose methods to read and update the state.

interface State {
  count: number;
}

interface StateStore {
  getState(): State;
  increment(): void;
}

const stateStore: StateStore = (function(): StateStore {
  const _state: State = {
    count: 0
  };

  return {
    getState: () => ({ ..._state }),
    increment: () => {
      _state.count++;
    }
  };
})();

function stateConsumerA() {
  stateStore.increment(); // original state count is incremented by one
  stateStore.getState().count = 100; // original state count is not mutated
}

function stateConsumerB() {
  console.log(stateStore.getState());
}

stateConsumerA();
stateConsumerB(); // log: {count: 1}

You might notice that instead of returning actual state value, we create its shallow copy. Therefore, when stateConsumerA attempts to mutate the state object, it does not affect the output from the stateConsumerB.

One could alternatively implement it using ES6 classes, which will be our preferred approach for the rest of that post.

class Store {
  private state: State = {
    count: 0
  };

  public getState(): State {
    return { ...this.state };
  }

  public increment() {
    this.state.count++;
  }
}

const stateStore = new Store();

Subscribing to state updates

Now, as you got an idea of what the state actually is, you might be wondering:
"OK, now I can update the state. But how do I know when the state was updated?".
The last missing piece is of cause subscribing to state updates. This is probably one reason why someone would bother about state management - to keep the application in sync.

There are a lot of brilliant state management solutions out there. But most of them have something in common - they rely on the Observer Pattern.
The concept is simple but though powerful. Subject keeps track of the state and its updates. Observers (in our case, state consumers) are attached to the subject and notified whenever the state changes.

type Observer = (state: State) => void;

An observer, in our case, is just a function that takes State as an input and performs some operations with this state.
Let's create an Observer that logs if count is odd or even:

function observer(state: State) {
  const isEven = state.count % 2 === 0;
  console.log(`Number is ${isEven ? "even" : "odd"}`);
}

Now we need to rework our Store class.

class Store {
  private state: State = {
    count: 0
  };

  private observers: Observer[] = [];

  public getState(): State {
    return { ...this.state };
  }

  public increment() {
    this.state.count++;
    this.notify(); // We need to notify observers whenever state changes
  }

  public subscribe(observer: Observer) {
    this.observers.push(observer);
  }

  private notify() {
    this.observers.forEach(observer => observer(this.state));
  }
}

Let's look at this example. Store, our Subject, contains information about the state and allows subscribing observers to the updates by adding them to the list and invoking with the latest state snapshot when it changes.
Here it is in action:

const stateStore = new Store();

stateStore.subscribe(observer);
stateStore.increment();
stateStore.increment();
stateStore.increment();

Our code will produce the following output:

Number is odd
Number is even
Number is odd

Although we haven't called our observer function, Subject does its job by notifying observers and calling them with the latest state snapshot.

Last but not least

The example discussed in this post is not exhaustive. In the real-world scenario, you should also take performance into account and unsubscribe, or detach observers, when necessary.

class Store {
  ...
  public unsubscribe(observer: Observer) {
    this.observers = this.observers.filter(item => item !== observer);
  }
  ...
}

Conclusion

State management is an important topic. We deal with it regardless of the technology, and therefore I think it's important to know how it works under the hood.
Let me know if you find this topic interesting, and I will be happy to elaborate on this in the future.
If you liked my posts, please spread the word and follow me on Twitter 🚀 and DEV.to for more exciting content about web development.

Rudo. Building Terminal UI with Rust

Gleb Irovich — Sat, 13 Feb 2021 19:30:31 +0000

Hey there, in today's post I would like to introduce you to my new pet project - Rudo. Rudo stands for "Rust To-do" and is a small terminal application that manages a list of to-dos.

Foreword

Back in 2020, locked down in isolation with my laptop and a thirst for a challenge, I decided to try out Rust. There are many reasons why I decided to give it a try, but the main one is, probably, the desire to push me out of the comfort zone.

Unlike programming languages which I know, Rust shifts a lot of control over low-level API to the programmer. All those tiny goodies that were perceived as given are now your own responsibility. It's painful... and it's exciting.

Firstly, I struggled. I fought with the compile for every line of code. I read awesome Rust's documentation again and again. I left it and started anew. And one day I realized that I love it. I loved how explicit the language was.

And that's how I programmed Rudo.

Motivation

Every new programming language starts with "Hello world".
Every front-end framework starts with a to-do app.

Why should I break these rules? 😄
As a front-end developer, I like visually observing my code in action. Wouldn't it be great to create a terminal UI then? I challenged myself to build an application using a terminal as a platform. How would UX for such an application be like? How would you navigate between application states? What would be the indicators and controls?
That's how Rudo was born.

Meet Rudo

Rudo is a simple to-do list manager. It's built with rs-tui and offers a clean and minimalistic layout to get things done. Keyboard-only input attempts to keep Rudo in line with your usual development workflow.
It's capable of doing a few things:

Creating and editing tasks 💃
Removing tasks from the list ❌
Toggling task state ✅
Filtering tasks 🏄‍♂️
Sorting tasks by date 🦾
Persisting tasks in a .json file 📀

Conclusion

Rudo is essentially an experiment. It's a prototype with some harsh edges, but made with ❤️ and fun 😎. Nonetheless, I am committed to continue improving Rudo and I am desperate to hear your feedback.
It's straightforward to use - download binaries, and you are good to go!
You can find everything in the README.

Please do not hesitate to express your opinion. You can reach me here on DEV.to or on Twitter.

Setting up Typescript project with Webpack

Gleb Irovich — Sun, 16 Aug 2020 15:05:38 +0000

In the Typescript 101 we have talked a lot about advantages of Typescript, discussed some use-cases, practices and tricks. Therefore, today I would like to show how you can start a new Typescript project from scratch. If you are using a front-end framework, everything happens inside of the black box, where webpack performs its magic. In this post, I would like to expose webpack configuration and demonstrate how you can spin up your next Typescript project in a couple of simple steps.

So what is the webpack? Webpack is a module bundler, a tool that gives you freedom of structuring your code however you like and takes an overhead of producing static assets, that you will be serving over the web. Webpack comes with a developed ecosystem of plugins that allow extending webpack with any additional utilities.

Table of content

Project setup
HTML templates
Webpack development server
Using JS libraries
Project styles

Project setup

To get started, let's initialize an empty npm project: npm init.
Here are some minimal dependencies we will need:

npm i webpack webpack-cli typescript ts-loader -D

At the end of this part, you must end up with the following directory structure:

We will start by configuring Typescript for that project. All you need to do is to include tsconfig.json in the project root with the following properties:

{
  "compilerOptions": {
    "outDir": "./dist/",
    "noImplicitAny": true,
    "module": "es6",
    "target": "es5",
    "allowJs": false,
    "sourceMap": true
  }
}

Now let's continue with setting up webpack. We will place webpack.config.js in the project root and add minimal configurations to get started:

const path = require('path');

module.exports = {
  mode: "production",
  entry: path.resolve(__dirname, './src/index.ts'),
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        use: 'ts-loader',
        exclude: /node_modules/,
      },
    ],
  },
  resolve: {
    extensions: ['.tsx', '.ts', '.js'],
  },
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist'),
  },
};

Some remarks here:

Default webpack mode is production, but it's always good to be explicit. In production mode webpack will minify your code
entry allows to configure entry points for your project, it can be a powerful tool should you decide to have code-splitting
The array of rules defines what actions bundler should undertake when it encounters a file of a specific type. For now, we only expect typescript files in the project, so we add only one rule, which will make use of ts-loader, a plugin, capable of parsing ts files.
In the output object one might provide a resulting file name and the directory where bundle assets will be added

That's it. Let's add an npm script to the package.json

...
  "scripts": {
    "build": "webpack"
  },
...

write some code to /src/index.ts

window.addEventListener("load", () => {
  const header = document.createElement("h1");
  header.innerText = "Webpack❤️TS"

  const body = document.querySelector("body");
  body.appendChild(header);
})

and build the project with: npm run build.

You will see that once your code is compiled, a new dist folder is added to the project root.

Congrats! You've built your first Typescript project! 🚀🚀

HTML templates

It's great to have a compiled script, now you can reference it in your html file, and you are good to go, right? No! 😀 Luckily webpack offers a better way to deal with that setup.

Firstly, we will install some additional dependencies: npm i html-webpack-plugin clean-webpack-plugin -D. We will also need a new templates folder where we will place our html template:

/src/templates/index.html:

<!doctype html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport"
          content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>Webpack❤️TS</title>
</head>
<body>

</body>
</html>

In the webpack.config.js we will use newly installed plugins:

html-webpack-plugin takes care of including your bundle to the html template
clean-webpack-plugin is a simple plugin which cleans up output folder on every build.

...
const HtmlWebpackPlugin = require('html-webpack-plugin');
const {CleanWebpackPlugin} = require("clean-webpack-plugin");

module.exports = {
  ...
  output: {
    filename: 'bundle.[hash].js', // <- ensure unique bundle name
    path: path.resolve(__dirname, 'dist'),
  },
  plugins: [
    new CleanWebpackPlugin(),
    new HtmlWebpackPlugin({
      template: path.resolve(__dirname, "./src/templates/index.html")
    })
  ]
};

You might notice that besides adding the plugins, we have changed the output file name. [hash] is a webpack keyword, that will add a hash to your bundle name. A unique name is essential to ensure that you always see up to date version in your browser window and not something cached.

Let's build again: npm run build. If you check out the dist folder now, you will see that webpack has produced a bundle with a hash in the file name as well as index.html which already includes you bundle in the script tag src.

/dist/index.html:

<!doctype html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width,user-scalable=no,initial-scale=1,maximum-scale=1,minimum-scale=1">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>Webpack❤️TS</title></head>
<body>
<script src="bundle.ff6beaa8d270fd22434a.js"></script>
</body>
</html>

That should be already sufficient for opening the html file in the browser, but can we do even better? 🤔
Sure we can!

Webpack development server

Webpack development server allows us to serve assets (such a surprise!) and enables live reload, whenever you change something in your code.

npm i webpack-development-server -D

While using webpack, it is common to split your configurations into several parts:

webpack.common.js - will include configurations that are shared between multiple setups. In our case dev vs prod
webpack.dev.js will include dev-specific configs such as webpack dev server, source map, etc
webpack.prod.js is responsible for configuring production build. It usually includes some optimization settings and ensures that the output is "production-ready".

// webpack.common.js
const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const {CleanWebpackPlugin} = require("clean-webpack-plugin");

module.exports = {
  entry: path.resolve(__dirname, './src/index.ts'),
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        use: 'ts-loader',
        exclude: /node_modules/,
      },
    ],
  },
  resolve: {
    extensions: ['.tsx', '.ts', '.js'],
  },
  output: {
    filename: 'bundle.[hash].js',
    path: path.resolve(__dirname, 'dist'),
  },
  plugins: [
    new CleanWebpackPlugin(),
    new HtmlWebpackPlugin({
      template: path.resolve(__dirname, "./src/templates/index.html")
    })
  ]
};

// webpack.dev.js
const webpackCommon = require('./webpack.common');
const path = require('path');

module.exports = {
  ...webpackCommon,
  devtool: "inline-source-map",
  mode: "development",
  devServer: {
    contentBase: path.join(__dirname, 'dist'),
    port: 3000
  }
};

// webpack.prod.js
const webpackCommon = require('./webpack.common');

module.exports = {
  ...webpackCommon,
  mode: "production",
};

We should also update npm script, to make sure, that a proper configuration file is used.

// package.json
...
  "scripts": {
    "start": "webpack-dev-server --config webpack.dev.js",
    "build": "webpack --config webpack.prod.js"
  },
...

Run npm start - your project will be available on http://localhost:3000

Using JS libraries

Now, as we have all set up, using a third-party library is very straightforward.
Let's include lodash as a dependency:

npm i lodash -S && npm i @types/lodash -D

And use it in the code:

import * as _ from "lodash";

window.addEventListener("load", () => {
    const header = document.createElement("h1");
    header.innerText = "Webpack❤️TS"

    const body = document.querySelector("body");
    body.appendChild(header);

    const food = [{id: 0, name: "pizza"}, {id: 1, name: "sushi"}]

    const foodElement = document.createElement("h2")
    foodElement.innerText = _.find(food, {id: 0})?.name;

    body.appendChild(foodElement);
})

Easy, right? 😇

Project styles

Probably the only missing piece now is the styles which we might want to include to our project. With webpack, you can use any style processor, but for the sake of the example, I will stick to the plain CSS.
As always, we will need some webpack plugins to handle the styles:

npm i css-loader mini-css-extract-plugin -D

Let's add them to the webpack.common.js:

// webpack.common.js
...
const MiniCssExtractPlugin = require('mini-css-extract-plugin');

module.exports = {
  ...
  module: {
    rules: [
      ...
      {
        test: /\.css$/i,
        use: [
          MiniCssExtractPlugin.loader,
          'css-loader'
        ],
      },
    ],
  },
  plugins: [
    ...
    new MiniCssExtractPlugin({filename: "styles.[hash].css"})
  ]
};

As webpack is a js-centric library, everything that we want to be included in the final bundle needs to be import in the .ts file:

// /src/styles.css
h2 {
    color: #1976d2;
}

// /src/index.ts
import "./styles.css";
import * as _ from "lodash";
...

Styles will be automatically included in the html file.
Run npm start for development and npm run build to create a production build! Good luck!

You can check out full code in my github repository!

If you liked my post, please spread a word and follow me on Twitter 🚀 for more exciting content about web development.

Go vs Rust for web dev

Gleb Irovich — Fri, 07 Aug 2020 07:32:00 +0000

What is a more suitable language for web development Go or Rust? Which one is the best one to pick to work with web assembly?

Why using JS classes instead of Typescript interfaces?

Gleb Irovich — Fri, 31 Jul 2020 05:40:54 +0000

As you know, in Typescript one might use JS classes as interfaces.

interface Post {
  title: string;
}

class Post {
  title: string;
}

What are the advantages of using classes (if any) instead of interfaces?

Typescript Data Structures: Linked List

Gleb Irovich — Fri, 24 Jul 2020 15:14:02 +0000

In today's episode of Typescript 101, we continue talking about data structures and their implementation in Typescript. Our today's patient is the linked list. We will dive into creating generic, reusable linked lists and touch the topic of recursion in JS. Welcome and let's hack!

Table of content

What is a linked list?
Nodes
Linked list's methods
Full implementation

What is a linked list?

According to the Wikipedia:
In computer science, a linked list is a linear collection of data elements whose order is not given by their physical placement in memory. Instead, each element points to the next. It is a data structure consisting of a collection of nodes which together represent a sequence.

There are two main types of linked lists:

Singly linked list: a list where elements have only a reference to next element
Doubly linked list: a list where elements are linked to both next and previous elements

Today we will focus on the doubly linked list implementation.

Nodes

Every item of the linked list is a node. Let's create a Node class first.

class Node<T> {
  public next: Node<T> | null = null;
  public prev: Node<T> | null = null;
  constructor(public data: T) {}
}

Since we are working on the doubly linked list our Node has next and prev fields, that point to another node or null. Also a Node contains our data, which has a generic type T.

Linked list's methods

Here is how the final version of the linked list will look like.

interface ILinkedList<T> {
  insertInBegin(data: T): Node<T>;
  insertAtEnd(data: T): Node<T>;
  deleteNode(node: Node<T>): void;
  traverse(): T[];
  size(): number;
  search(comparator: (data: T) => boolean): Node<T> | null;
}

Insert

We will start by implementing insert functionality. There are multiple ways to insert data to the linked list. One might insert data after or before a certain node or based on the index, but in this example, we will focus on more generic cases - inserting nodes in the beginning or at the end of the list.

insertInBegin

class LinkedList<T> implements ILinkedList<T> {
  private head: Node<T> | null = null;

  public insertInBegin(data: T): Node<T> {
    const node = new Node(data);
    if (!this.head) {
      this.head = node;
    } else {
      this.head.prev = node;
      node.next = this.head;
      this.head = node;
    }
    return node;
  }
}

Here we are handling two scenarios:

The list is empty - in that case, the newly added element becomes the head of the list.
The list is not empty - in that case newly added element becomes the head of the list and we update the links of the former head.

1. list Before insertion:
A <-> B <-> ...
2. list after insertion:
New_Node <-> A <-> B <-> ...

insertAtEnd

class LinkedList<T> implements ILinkedList<T> {
  private head: Node<T> | null = null;

  public insertAtEnd(data: T): Node<T> {
    const node = new Node(data);
    if (!this.head) {
      this.head = node;
    } else {
      const getLast = (node: Node<T>): Node<T> => {
        return node.next ? getLast(node.next) : node;
      };

      const lastNode = getLast(this.head);
      node.prev = lastNode;
      lastNode.next = node;
    }
    return node;
  }
}

Inserting, in the end, is a bit trickier, because we need to find the last node first, so let's look closer at what's happening. Similarly to the previous method, we have two scenarios:

The list is empty - in that case, the newly added element becomes the head of the list.
The list is not empty - we search for the last node and set it's next reference to the newly added element.

A <-> B <-> New_Node

To find the last node we are using a recursive function, which traverses the list and return the node which does not have a reference to the next node:

const getLast = (node: Node<T>): Node<T> => {
  return node.next ? getLast(node.next) : node;
};

Delete

Deleting a node is quite straightforward. All we need to do is updating the references for the next and previous items. If the node is the current head, we will have to shift our list.

class LinkedList<T> implements ILinkedList<T> {
  private head: Node<T> | null = null;

  public deleteNode(node: Node<T>): void {
    if (!node.prev) {
      this.head = node.next;
    } else {
      const prevNode = node.prev;
      prevNode.next = node.next;
    }
  }
}

Traverse

traverse method will iterate over the linked list and return all nodes as JS Array. For this method we will also make use of a recursive function.

class LinkedList<T> implements ILinkedList<T> {
  private head: Node<T> | null = null;

  public traverse(): T[] {
    const array: T[] = [];
    if (!this.head) {
      return array;
    }

    const addToArray = (node: Node<T>): T[] => {
      array.push(node.data);
      return node.next ? addToArray(node.next) : array;
    };
    return addToArray(this.head);
  }
}

Recursive functions are a great substitute of while loops for the tasks like traversing when we don't know the size of the list before we start iterating.

Size

To keep track of the size, we can store a current number of nodes in a class field and update it every time a node is added or removed. However, in this example, I will simply make use of the traverse function and return array length:

...
  public size(): number {
    return this.traverse().length;
  }
...

Search

When you think about the final consumer of the LinkedList class, she'll be probably interested in searching for the node based on some data property. To make usage of our search method as flexible as possible, we'll be using the inversion of control. The consumer will be able to pass a callback function, which would implement the required search condition:

class LinkedList<T> implements ILinkedList<T> {
  private head: Node<T> | null = null;

  public search(comparator: (data: T) => boolean): Node<T> | null {
    const checkNext = (node: Node<T>): Node<T> | null => {
      if (comparator(node.data)) {
        return node;
      }
      return node.next ? checkNext(node.next) : null;
    };

    return this.head ? checkNext(this.head) : null;
  }
}

Full implementation

class LinkedList<T> implements ILinkedList<T> {
  private head: Node<T> | null = null;

  public insertAtEnd(data: T): Node<T> {
    const node = new Node(data);
    if (!this.head) {
      this.head = node;
    } else {
      const getLast = (node: Node<T>): Node<T> => {
        return node.next ? getLast(node.next) : node;
      };

      const lastNode = getLast(this.head);
      node.prev = lastNode;
      lastNode.next = node;
    }
    return node;
  }

  public insertInBegin(data: T): Node<T> {
    const node = new Node(data);
    if (!this.head) {
      this.head = node;
    } else {
      this.head.prev = node;
      node.next = this.head;
      this.head = node;
    }
    return node;
  }

  public deleteNode(node: Node<T>): void {
    if (!node.prev) {
      this.head = node.next;
    } else {
      const prevNode = node.prev;
      prevNode.next = node.next;
    }
  }

  public search(comparator: (data: T) => boolean): Node<T> | null {
    const checkNext = (node: Node<T>): Node<T> | null => {
      if (comparator(node.data)) {
        return node;
      }
      return node.next ? checkNext(node.next) : null;
    };

    return this.head ? checkNext(this.head) : null;
  }

  public traverse(): T[] {
    const array: T[] = [];
    if (!this.head) {
      return array;
    }

    const addToArray = (node: Node<T>): T[] => {
      array.push(node.data);
      return node.next ? addToArray(node.next) : array;
    };
    return addToArray(this.head);
  }

  public size(): number {
    return this.traverse().length;
  }
}

interface Post {
  title: string;
}
const linkedList = new LinkedList<Post>();

linkedList.traverse() // [];

linkedList.insertAtEnd({ title: "Post A" });
linkedList.insertAtEnd({ title: "Post B" });
linkedList.insertInBegin({ title: "Post C" });
linkedList.insertInBegin({ title: "Post D" });

linkedList.traverse() // [{ title : "Post D" }, { title : "Post C" }, { title : "Post A" }, { title : "Post B" }];
linkedList.search(({ title }) => title === "Post A") // Node { data: { title: "Post A" }, prev: Node, next: Node};

Summary

Today we talked linked lists, and I hope you've found it useful. If you want to learn something specific about Typescript or willing to propose the next data structure, leave a comment and let's discuss it together.

If you liked my post, please spread a word and follow me on Twitter 🚀 for more exciting content about web development.

Typescript Data Structures: Stack and Queue

Gleb Irovich — Mon, 13 Jul 2020 17:54:51 +0000

One of the most exciting things about Typescript is that it encourages developers to think in terms of "blueprints" rather than writing code straight away. In today's post, we will start talking about the data structures and their implementations in Typescript. We will begin by discussing stacks and queues as well as looking into some basics of abstract classes.

Table of content

Stack
Queue
Abstract Classes

Stack

A stack is an elementary data structure, that is often described as LIFO (last in first out). An item that was added the last is the first to be retrieved. Usually, stacks have the following methods:

push adds an item to the stack
pop returns the last added item and remove it from the stack
peek (optional) returns the last added item without removing it from the stack

Stack also has some properties:

storage represents all stacked items
capacity (optional) is a number of items a stack can fit

Let's define a generic interface for the Stack:

interface IStack<T> {
  push(item: T): void;
  pop(): T | undefined;
  peek(): T | undefined;
  size(): number;
}

Typescript interfaces don't allow to define private properties, therefore storage and capacity are omitted in IStack interface.

Now as we have an interface in place we can implement it and create our Stack class.

class Stack<T> implements IStack<T> {
  private storage: T[] = [];

  constructor(private capacity: number = Infinity) {}

  push(item: T): void {
    if (this.size() === this.capacity) {
      throw Error("Stack has reached max capacity, you cannot add more items");
    }
    this.storage.push(item);
  }

  pop(): T | undefined {
    return this.storage.pop();
  }

  peek(): T | undefined {
    return this.storage[this.size() - 1];
  }

  size(): number {
    return this.storage.length;
  }
}

const stack = new Stack<string>();
stack.push("A");
stack.push("B");

stack.size(); // Output: 2
stack.peek(); // Output: "B"
stack.size(); // Output: 2
stack.pop();  // Output: "B"
stack.size(); // Output: 1

Two noticeable things are happening in that example:

Constructor assignment constructor(private capacity: number = Infinity) {} is a short-hand for assigning a property in the constructor.
Implementation of a generic interface by a class with a generic type. new Stack<string>() will implement an interface IStack<string>. Typed passed to the class will also be used in the interface.

Implementing an interface is a type-safe way to ensure that all required methods are available in the class.

Queue

Queues are very similar to the stacks, but they handle items FIFO (first in first out). Items will be retrieved from the queue in the same order as they were added. Queues have the following methods:

enqueue adds an item to the queue
dequeue retrieves an item from the queue
size returns the size of the queue

Let's start with an interface:

interface IQueue<T> {
  enqueue(item: T): void;
  dequeue(): T | undefined;
  size(): number;
}

Here is the implementation:

class Queue<T> implements IQueue<T> {
  private storage: T[] = [];

  constructor(private capacity: number = Infinity) {}

  enqueue(item: T): void {
    if (this.size() === this.capacity) {
      throw Error("Queue has reached max capacity, you cannot add more items");
    }
    this.storage.push(item);
  }
  dequeue(): T | undefined {
    return this.storage.shift();
  }
  size(): number {
    return this.storage.length;
  }
}

const queue = new Queue<string>();

queue.enqueue("A");
queue.enqueue("B");

queue.size();    // Output: 2
queue.dequeue(); // Output: "A"
queue.size();    // Output: 1

Abstract Classes

At this point, we can already notice some patterns. Both stacks and queues have storage and capacity properties as well as the size method.
Luckily in Typescript, we can use abstract classes. Abstract classes have a major difference from regular JS classes -- they cannot be directly instantiated. They can only be extended.

abstract class Collection<T> {
  protected storage: T[] = [];

  size(): number {
    return this.storage.length;
  }
  abstract isFull(): boolean;
}

protected property or method restricts its usage to the derived classes only.
abstract methods shall be implemented in the derived class and serve as a blueprint.

Now let's look at how Stack and Queue classes can be implemented with the help of the abstract Collection class.

Stack

class StackCollection<T> extends Collection<T> implements IStack<T> {
  constructor(private capacity: number = Infinity) {
    super();
  }

  push(item: T) {
    if (this.isFull()) {
      throw Error("Stack has reached max capacity, you cannot add more items");
    }
    // In the derived class, we can access protected properties of the abstract class
    this.storage.push(item);
  }

  pop(): T | undefined {
    return this.storage.pop();
  }

  peek(): T | undefined {
    return this.storage[this.size() - 1];
  }

  // Implementation of the abstract method
  isFull(): boolean {
    return this.capacity === this.size();
  }
}

Queue

class QueueCollection<T> extends Collection<T> implements IQueue<T> {
  constructor(private capacity: number = Infinity) {
    super();
  }
  enqueue(item: T): void {
    if (this.isFull()) {
      throw Error("Queue has reached max capacity, you cannot add more items");
    }
    // In the derived class, we can access protected properties of the abstract class
    this.storage.push(item);
  }
  dequeue(): T | undefined {
    return this.storage.shift();
  }

  // Implementation of the abstract method
  isFull(): boolean {
    return this.capacity === this.size();
  }
}

Today we talked about elementary data structures and their implementation in Typescript. If you want to learn something specific about Typescript or webdev in general, leave a comment and let's discuss it together.

If you liked my post, please spread a word and follow me on Twitter 🚀 for more exciting content about web development.

5 Typescript utility types, that will make your life easier

Gleb Irovich — Mon, 06 Jul 2020 19:26:27 +0000

Luckily for us, developers, Typescript is shipped with a lot of handy utility types. They are meant to improve the readability of the code and reduce the boilerplate while working with types. In today's episode of Typescript 101, I would like to talk about 5 utility types, which I find especially useful in everyday development.

Table of content

Omit
Pick
Partial
Readonly
Record

1. Omit

Omit<T, K> according to the official documentation Constructs a type by picking all properties from T and then removing K. In other words Omit is a generic utility type, that drops keys of T specified in K. One of the use-cases where you might need this utility is working with DTOs. If your project is using a strict serialisation, you might find yourself creating a lot of boilerplate code to describe different DTOs. Let's consider an example of how we can benefit from Omit in that case:

interface Post {
  id: number;
  title: string;
  createdAt: string;
}

type CreatePostDto = Omit<Post, "id" | "createdAt">;

const createDto: CreatePostDto = {
  title: "My post",
  id: 1, // error
  createdAt: "2020-06-06" // error
};

Properties like id or createdAt are usually set by the backend and you don't have them available while creating a new entity via the API. You can simply describe this situation by omitting those keys from the Post interface.

2. Pick

Pick does the opposite of Omit. Pick<T, K> Constructs a type by picking the set of properties K from T. Continuing the same example with DTOs, here is how you can define a type of UpdatePostDto :

type UpdatePostDto = Pick<Post, "id" | "title">;

const updateDto: UpdatePostDto = {
  id: 1,
  title: "My new post",
  createdAt: "2020-06-06" // error
};

Pick and Omit can be used to achieve the same goal because Pick<Post, "id" | "title"> is the same as Omit<Post, "createdAt">. You can always decide what is shorter or more readable to use.

3. Partial

Partial<T> is a generic utility type, that makes all properties of the provided interface optional. My favourite example of using Partial is updating objects via merging. It's especially common when you are working with state management and state updates.

interface AppState {
  posts: Post[];
  userName: string;
}

function updateState(state: AppState, update: Partial<AppState>): AppState {
  return { ...state, ...update };
}

const initialState: AppState = {
  posts: [],
  userName: "Gleb"
};

const update: Partial<AppState> = {
  userName: "John"
};

updateState(initialState, update);

Partial sets all properties of AppState to optional and therefore allows you to define only updated keys, without losing type safety.

4. Readonly

Readonly<T> is another handy utility, which helps while working with immutable data. If you'd like to enforce immutability try using Readonly:

const state: Readonly<AppState> = {
  posts: [],
  userName: "Gleb"
};

state.posts = []; // error: Cannot assign to 'posts' because it is a read-only property.
const updatedState: Readonly<AppState> = { ...state, posts: [] }; // ok

5. Record

I have already talked about Record<T, K> in this post, but this utility is definitely worth mentioning one more time.
During my daily duties, I have to deal a lot with data grids. Most of them have a very similar pattern: they define every row as a key-value map. It's often the case that the row interface can be defined quite loosely:

type Cell = string;

interface Row {
  [key: string]: Cell;
}

It means that you can potentially add as many keys as you want. Here is an example of the row that represents a single post object:

const post: Post = { id: 1, title: "My post", createdAt: "2020-06-06" };

const row: Row = {
  title: post.title,
  createdAt: post.createdAt,
  randomKey: "is allowed"
};

Luckily there is a nice way to constrain allowed keys by using Record:

type PostRow = Record<keyof Post, Cell>;

const postRow: PostRow = {
  id: post.id.toString(),
  title: post.title,
  createdAt: post.createdAt,
  randomKey: "is not allowed" // error
};

This approach makes the expected type of the row transparent to the developers and keeps it type-safe. Also with just a little effort, you can create a reusable generic row type:

type PostRow<T> = Record<keyof T, Cell>;

const postRow: PostRow<Post> = {
  id: post.id.toString(),
  title: post.title,
  createdAt: post.createdAt,
  randomKey: "is not allowed" // error
};

Summary

Today we discovered some superpowers of Typescript utility types and I hope you have enjoyed exploring them with me! I am very interested in your feedback. If you want to learn something specific about Typescript or webdev in general, leave a comment and let's discuss it together.

If you liked my post, please spread a word and follow me on Twitter 🚀 for more exciting content about web development.

What is the most challenging thing in Typescript?

Gleb Irovich — Thu, 02 Jul 2020 05:22:45 +0000

4 Ideas of how to harness the power of Typescript generic function

Gleb Irovich — Mon, 29 Jun 2020 19:15:41 +0000

Typescript is a powerful tool that significantly improves the reliability of the javascript code. However, it also adds particular overhead, that developers have to deal with while working with Typescript.

Generic functions are, probably, one of the trickiest but though most powerful concepts of Typescript. In my previous post I briefly touched the topic generics, however, now I would like to dig deeper, and talk about how we can harness the power of generics to deliver scalable and reusable code. Today we will consider four ideas of generic helper functions made with ❤️and powered by Typescript.

Disclaimer

If you are looking for an ultimate solution with a lot of different methods, you might be interested in checking out great existing libraries such ramda or lodash. The purpose of this post is to discuss some examples, which I find useful in everyday development, and which are suitable for the illustration of Typescript generics. Feel free to add your use-cases in the comments, let's discuss them together 💪

Table of content

Map by key
Group by key
Merge
Sort

Before we start

For the sake of example, I came up with two simple interfaces and created arrays out of them.

interface Book {
  id: number;
  author: string;
}

interface Recipe {
  id: number;
  cookingTime: number;
  ingredients: string[];
}

const books: Book[] = [
  { id: 1, author: "A" },
  { id: 2, author: "A" },
  { id: 3, author: "C" }
]

const recipes: Recipe[] = [
  { id: 1, cookingTime: 10, ingredients: ["salad"] },
  { id: 2, cookingTime: 30, ingredients: ["meat"] }
]

1. Map by key

interface Item<T = any> {
  [key: string]: T
}

function mapByKey<T extends Item>(array: T[], key: keyof T): Item<T> {
  return array.reduce((map, item) => ({...map, [item[key]]: item}), {})
}

Let's look closer to what happens here:

interface Item<T = any> { ... } is a generic interface, with a default value of any (yes you can have default values in generics 🚀)
<T extends Item>(array: T[], key: keyof T) : Type T is inferred from the parameter, but it must satisfy the condition <T extends Item> (in other words T must be an object).
key: keyof T second parameter is constrained to the keys which are only available in T. If we are using Book, then available keys are id | author.
(...): Item<T> is a definition of the return type: key-value pairs, where values are of type T

Let's try it in action:

mapByKey(books, "wrongKey") // error. Not keyof T -> (not key of Book)

mapByKey(books, "id") // {"1":{"id":1,"author":"A"},"2":{"id":2,"author":"A"},"3":{"id":3,"author":"C"}}

As you can see, we can now benefit from knowing in advance available keys. They are automatically inferred from the type of the first argument. Warning: this helper is handy with unique values like ids; however, if you have non-unique values, you might end up overwriting a value which was previously stored for that key.

2. Group by key

This method is beneficial, if you need to aggregate data based on a particular key, for instance, by author name.

We start by creating a new interface, which will define our expected output.

interface ItemGroup<T> {
  [key: string]: T[];
}

function groupByKey<T extends Item>(array: T[], key: keyof T): ItemGroup<T> {
  return array.reduce<ItemGroup<T>>((map, item) => {
    const itemKey = item[key]
    if(map[itemKey]) {
      map[itemKey].push(item);
    } else {
      map[itemKey] = [item]
    }

    return map
  }, {})
}

It's interesting to note, that Array.prototype.reduce is a generic function on its own, so you can specify the expected return type of the reduce to have better typing support.

In this example, we are using the same trick with keyof T which under the hood resolves into the union type of available keys.

groupByKey(books, "randomString") // error. Not keyof T -> (not key of Book)
groupByKey(books, "author") // {"A":[{"id":1,"author":"A"},{"id":2,"author":"A"}],"C":[{"id":3,"author":"C"}]}

3. Merge

function merge<T extends Item, K extends Item>(a: T, b: K): T & K {
  return {...a, ...b};
}

In the merge example T & K is an intersection type. That means that the returned type will have keys from both T and K.

const result = merge(books[0], recipes[0]) // {"id":1,"author":"A","cookingTime":10,"ingredients":["bread"]}
result.author // "A"
result.randomKey // error

4. Sort

What is the problem with Array.prototype.sort method? → It mutates the initial array. Therefore I decided to suggest a more flexible implementation of the sorting function, which would return a new array.

type ValueGetter<T = any> = (item: T) => string | number;
type SortingOrder = "ascending" | "descending";

function sortBy<T extends Item>(array: T[], key: ValueGetter<T>, order: SortingOrder = "ascending") {
  if(order === "ascending") {
    return [...array].sort((a, b) => key(a) > key(b) ? 1 : -1 )
  }
  return [...array].sort((a, b) => key(a) > key(b) ? -1 : 1 )
}

We will use a ValueGetter generic function, which will return a primitive type: string or number. It is a very flexible solution because it allows us to deal with nested objects efficiently.

// Sort by author
sortBy(books, (item) => item.author, "descending")

// Sort by number of ingredients
sortBy(recipes, (item) => item.ingredients.length)

// Sort very nested objects
const arrayOfNestedObjects = [{ level1: { level2: { name: 'A' } } }]
sortBy(arrayOfNestedObjects, (item) => item.level1.level2.name)

Summary

In this post, we played around with generic functions in Typescript by writing helper functions for common operations with JS arrays and objects. Typescript provides a variety of tools to produce reusable, composable and type-safe code, and I hope you are enjoying to explore them with me!

If you liked my post, please spread a word and follow me on Twitter 🚀for more exciting content about web development.

5 TypeScript features that will improve your codebase

Gleb Irovich — Mon, 22 Jun 2020 18:25:37 +0000

The emergence of typescript changed the way how developers deal with javascript applications. It brings not only code reliability with type-safety, but also improves developer experience, by providing powerful refactoring capabilities and smarter ways to write JS code.

In this post I would like to talk about five typescript features, that will improve your codebase.

Table of content

Nullish coalescing
Type guards
Enum object keys
Generic interfaces
Generic function parameter types

1. Nullish coalescing

Let's consider the following example.

function getNumberOrDefault(value?: number) {
  return value || 22;
}

In the mentioned example, we would like to return a default value, if the provided value is undefined. However, this code has a severe pitfall — javascript treats 0 as a falsy value.

console.log(getNumberOrDefault(10)) // Output 10
console.log(getNumberOrDefault(0)) // Output 22

Returning 22 is probably, not something we expect this function to do. Thanks to the nullish coalescing we don't need to refactor the code and add check for 0, instead we can use a shorthand syntax with ??.

function getNumberOrDefaultTs(value?: number) {
    return value ?? 22;
}

console.log(getNumberOrDefault(10)) // Output 10
console.log(getNumberOrDefault(0)) // Output 0

2. Type guards

Let's imagine we have two types, Truck and F1, which extend the same interface Car. Although they share some common properties, they also possess a set of unique attributes like load and acceleration respectively.

interface Car {
  model: string;
}

interface Truck extends Car {
  load: number;
}

interface F1 extends Car {
  acceleration: number;
}

function scanCar(car: Truck | F1) {
    ...some code
}

Also, we have a function scanCar which accepts either a Truck or a F1 and performs some type-specific actions.

Type guard is a great way to let typescript know with which type we are currently dealing.

function carIsTruck(car: Truck | F1): car is Truck {
  return 'load' in car;
}

function scanCar(car: Truck | F1) {
  if(carIsTruck(car)) {
        // Only truck properties will be suggested
    console.log(`Truck has a load of ${car.load}`)
  } else {
        // Only F1 properties will be suggested
    console.log(`F1 has acceleration of ${car.acceleration}`)
  }
}

Type guard is a function that returns a boolean, which is often used as part of the conditional statement, to let typescript know which type is assumed in the current if block.

3. Enum object keys

There are some cases when we want to enforce object keys being certain values only. And here is how we can achieve it using enum and Record.

enum Size {
  M,
  L,
  XL
}

function getPlainTextSizes(): Record<Size, string> {
  return {
    [Size.M]: "medium",
    [Size.L]: "large",
    [Size.XL]: "extra large",
    10: "small", // error
    "size": "xs" // error
  }
}

Record is a generic type util, which allows defining types for key-value maps.

4. Generic interfaces

interface Item<T> {
  id: number,
  value: T,
}

interface Post {
  title: string;
}

const item1: Item<number> = { id: 1, value: 10 }
const item2: Item<Post> = { id: 1, value: { title: "Post name" } }

Generics in typescript significantly improve code reusability.

5. Generic function parameter types

interface Book {
  id: number;
  author: string;
}

interface Recipe {
  id: number;
  cookingTime: number;
}

function mapById<T extends { id: number }>(array: T[]): {[key: number]: T} {
  return array.reduce((map, item) => ({ ...map, [item.id]: item }), {})
}

const books: Book[] = [{ id: 1, author: "A" }];
const recipies: Recipe[] = [{ id: 1, cookingTime: 10 }];

mapById(books);
mapById(recipies);

It's often the case that we have util functions which require only some field from the interface. In the example above you can see a function which takes an array as input and returns values mapped by id. The only important thing is that the items of the array have an id. When you pass a parameter to the function typescript will:

Infere the type of the provided parameter
Check if the parameter matches specified condition (must have id of type number) So now you are save to use this helper for various interfaces.

Summary

As you can see typescript provides a lot of tools to write reusable and flexible code without sacrificing type safety.

Thanks for reading! This post is an experiment with a new format, let me know if you find it interesting and helpful. Help to spread the word and follow me on Twitter for more cool stuff about web dev! 🚀

Angular in React Terms: Application Routing

Gleb Irovich — Tue, 16 Jun 2020 16:17:18 +0000

In today's episode, I would like to talk about application routing. We will look into some basics of working with Router in Angular and React and consider how those routers are different.

Angular being a "batteries included" framework is supplied with a Router module already. Therefore starting to use a router is a matter of importing that module. However, for React development, there are a couple of different routing libraries available. In this post, we will use react-router which is, probably, the most well-known among them.

Static vs Dynamic Routing

Before we dive into comparing routing implementation in the apps, it's essential to understand the fundamental difference between the two routers.

Angular Router provides static routing. That means that all routes are declared during the app initialisation. Depending on the app size routing is usually defined either for the entire project in the app-routing.module.ts or for every view module individually.

React Router (since v4), on the other side, employs a concept of dynamic routing. Routes are declared during the application render. Every router piece is a React component which makes it very modular and flexible. Dynamic routing allows changing route structure on the fly, for example, it can change based on some conditional logic.

Simple routing

Now let's look at the Angular and React routing in action. Let's imagine that we are building an application for an e-commerce store. It will have a home page, product catalogue and a page for every product with a short description.

In Angular we create our HomePageComponent and ProductsPageComponent as well as provide routing definition in app-routing.module.ts.

// Angular
// app.component.ts
@Component({
  selector: 'app-home-page',
  template: `<div>I am a home page</div>`,
})
export class HomePageComponent {}

@Component({
  selector: 'app-product-page',
  template: `
    <ul>
      <li *ngFor="let product of products">{{ product.value }}</li>
    </ul>
  `,
})
export class ProductsPageComponent {
  public products = [
    { id: 1, value: 'candies' },
    { id: 2, value: 'ice cream' },
  ];
}

@Component({
  selector: 'app-root',
  template: `
    <nav>
      <ul>
        <li><a routerLink="/">Home</a></li>
        <li><a routerLink="/products">Products</a></li>
      </ul>
    </nav>
    <router-outlet></router-outlet>
  `,
})
export class AppComponent {}

// Angular
// app-routing.module.ts
const routes: Routes = [
  {
    path: '',
    component: HomePageComponent,
  },
  {
    path: 'products',
    component: ProductsPageComponent,
  },
];

@NgModule({
  imports: [RouterModule.forRoot(routes)],
  exports: [RouterModule],
})
export class AppRoutingModule {}

// Angular
// app.module.ts
@NgModule({
  declarations: [AppComponent, HomePageComponent, ProductsPageComponent],
  // Now we can use our routing module in the app.
  imports: [CommonModule, BrowserModule, AppRoutingModule],
  providers: [],
  bootstrap: [AppComponent],
})
export class AppModule {}

Here is how Angular Router works:

Router listens to the changes in the URL
If there is a match with one of the defined paths, Router will execute route-guards and resolvers
Then a component specified in the component field will be rendered in the router-outlet

router-outlet is a special Angular component, which, similarly to ng-content, is used as a placeholder for the content matching current URL.

// React
const HomePage = () => {
  return <div>I am a home page</div>
}

const ProductsPage = () => {
  const products = [{id: 1, value: "candies"}, {id: 2, value: "ice cream"}]
  return (
    <ul>
      { products.map((product) => <li key={product.id}>{product.value}</li> ) }
    </ul>
  )
}

function App() {
  return (
    <BrowserRouter>
      <nav>
        <ul>
          <li><Link to="/">Home</Link></li>
          <li><Link to="/products">Products</Link></li>
        </ul>
      </nav>

      <Switch>
        <Route path="/products"><ProductsPage /></Route>
        <Route path="/"><HomePage /></Route>
      </Switch>
    </BrowserRouter>
  );
}

export default App;

To enable routing in React, we need to wrap our application with BrowserRouter and define routes in the Switch. Anything added inside the Route component, will be rendered if route path matches the URL.

Redirects

Now let's assume we want our home page to be available on the /home path instead of the root. Let's update the routing and make sure, if the user visits the root she is redirected to the proper home page.

// Angular
// app-routing.module.ts
const routes: Routes = [
  {
    path: '',
    redirectTo: 'home',
    pathMatch: 'full',
  },
  {
    path: 'products',
    component: ProductsPageComponent,
  },
  {
    path: 'home',
    component: HomePageComponent,
  },
];

// React
function App() {
  return (
    <BrowserRouter>
      <nav>
        <ul>
          <li><Link to="/home">Home</Link></li>
          <li><Link to="/products">Products</Link></li>
        </ul>
      </nav>

      <Switch>
        <Route path="/products"><ProductsPage /></Route>
        <Route path="/home"><HomePage /></Route>
        <Redirect from="/" to="/home" />
      </Switch>
    </BrowserRouter>
  );
}

Unlike an additional route definition in Angular, In React, Redirect is a component from the react-router library, which will handle redirects for your app.

Route parameters

Application routing is especially helpful when we want to share some state across the application via the URL parameters. To enable dynamic parameters we only have to add a new route listener with a parameter name. Both Angular and React use :paramName syntax to map value to the parameter name.

// Angular
// app-routing.module.ts
const routes: Routes = [
    ...
  {
    path: 'products',
    children: [
      { path: '', component: ProductsPageComponent },
      { path: ':productId', component: SingleProductPageComponent },
    ],
  },
    ...
];

// Angular
// app.component.ts
...
@Component({
  selector: 'app-product-page',
  template: `
    <ul>
      <li *ngFor="let product of products" [routerLink]="product.id">
                <!-- routerLink is a directive which helps navigating application router -->
        <a [routerLink]="product.id">{{ product.value }}</a>
      </li>
    </ul>
  `,
})
export class ProductsPageComponent {
  public products = [
    { id: 1, value: 'candies' },
    { id: 2, value: 'ice cream' },
  ];
}

@Component({
  selector: 'app-single-product-page',
  template: ` <div>{{ product$ | async | json }}</div> `,
})
export class SingleProductPageComponent {
  product$ = this.activatedRoute.paramMap.pipe(
    map((params) => params.get('productId')),
    map((id) => this.products[id])
  );

  // Data about the product might be coming from the API or from the application state.
  private products = {
    1: {
      name: 'candies',
      description: 'candies are sweet',
    },
    2: {
      name: 'ice cream',
      description: 'ice cream is cold',
    },
  };

  constructor(private activatedRoute: ActivatedRoute) {}
}

// React
...
const ProductsPage = () => {
  const products = [{id: 1, value: "candies"}, {id: 2, value: "ice cream"}]
  return (
    <ul>
      { products.map((product) =>  (
        <li key={product.id}>
          {/* We can use Link component to navigate application router */}
          <Link to={`/products/${product.id}`}>{product.value}</Link>
        </li>
      )) }
    </ul>
  )
}

const SingleProductPage = () => {
  // useParams hooks help accessing router context and retrieving parameter values
  const { productId } = useParams()
  // Data about the product might be coming from the API or from the application state.
  const products = {
    1: {
      name: 'candies',
      description: 'candies are sweet',
    },
    2: {
      name: 'ice cream',
      description: 'ice cream is cold',
    },
  };
  return <div>{JSON.stringify(products[productId])}</div>
}

function App() {
  return (
    <BrowserRouter>
      <nav>
        <ul>
          <li><Link to="/home">Home</Link></li>
          <li><Link to="/products">Products</Link></li>
        </ul>
      </nav>

      <Switch>
        <Route path="/products/:productId"><SingleProductPage /></Route>
        <Route path="/products"><ProductsPage /></Route>
        <Route path="/home"><HomePage /></Route>
        <Redirect from="/" to="/home" />
      </Switch>
    </BrowserRouter>
  );
}

As you can see, using route parameters is very similar in Angular and React. To dynamically navigate inside the app, we are using routerLink directive in Angular and Link component in React. The only significant difference is accessing route parameters from the component.

In Angular we have to inject ActivatedRoute, a special class that keeps the information about the current route and its available parameters. React Router on the other side uses Context API which can be accessed by hooks (like in the example above).

Summary

Although router implementations for Angular and React are different, using them in the application is very similar. To make it work we need just three pieces of code:

Routes definition
Components that are rendered when the route is activated
Access to the ActivatedRoute or RouterContext if you want to retrieve parameters

Thanks for reading! If you like my posts help to spread the word and follow me on Twitter 🚀