DEV Community: Michal M.

Typescript wrapper class for browser storage

Michal M. — Fri, 05 Dec 2025 20:09:05 +0000

In your front-end applications, you probably use localStorage or sessionStorage to store various types of data. Each browser's API allows you to use an object with the same names for this purpose. In this post, I'd like to demonstrate how to use this functionality in a consistent and organized manner.

I'll present the final code now and describe its fragments later in this post.

interface StorageServiceInterface {
  setItem<T>(key: string, value: T): void;
  getItem<T>(key: string): T | null;
  removeItem(key: string): void;
  clear(): void;
  getStorage(): Storage;
}

class StorageService implements StorageServiceInterface {
  storagePrefix?: string = "";

  constructor(readonly storage: Storage, storagePrefix?: string) {
    this.storagePrefix = storagePrefix;
  }

  private buildKey(key: string): string {
    return this.storagePrefix ? `${this.storagePrefix}-${key}` : key;
  }

  private serialize<T>(value: T): string {
    return JSON.stringify(value);
  }


  private deserialize<T>(value: string): T {
    return JSON.parse(value) as T;
  }

  public setItem<T>(key: string, value: T) {
    const storageKey = this.buildKey(key);
    const stringValue = this.serialize(value);
    try {
      this.storage.setItem(storageKey, stringValue);
    } catch (err) {
      throw err;
    }
  }

  public getItem<T>(key: string): T | null {
    const storageKey = this.buildKey(key);
    const item = this.storage.getItem(storageKey);
    if (!item) return null;
    try {
      return this.deserialize<T>(item);
    } catch {
      return null;
    }
  }

  public removeItem(key: string) {
    const storageKey = this.buildKey(key);
    this.storage.removeItem(storageKey);
  }

  public getKeys(withPrefix = false): string[] {
    const keys: string[] = [];
    for (let i = 0; i < this.storage.length; i++) {
      const fullKey = this.storage.key(i);
      if (fullKey) {
        if (this.storagePrefix) {
          if (fullKey.startsWith(`${this.storagePrefix}-`)) {
            const cleanKey = fullKey.replace(`${this.storagePrefix}-`, "");
            keys.push(withPrefix ? fullKey : cleanKey);
          }
        } else {
          keys.push(fullKey);
        }
      }
    }
    return keys;
  }

  public clear() {
    this.storage.clear();
  }

  public getStorage(): Storage {
    return this.storage;
  }
}

export const localStorageService = new StorageService(
  localStorage,
  "MY_APP_PREFIX"
);

We start with an interface declaration: StorageServiceInterface. This isn't necessary, but I like to declare interfaces so that the user can quickly access the public properties this class provides. Remember - when a class implements an interface, the members declared on the interface must be publicly accessible within the class.

In the class constructor, you must pass the store type – this can be localStorage or sessionStorage. Optionally, you can also pass a prefix that will be assigned to each key created from this class. I find this very useful for adding another layer of unique values that can potentially be included in localStorage. From experience, I recommend the application name or username. This increases the chance of unique names. It's also easier to manage a group of keys if they have a repeating pattern in its name.

The next three private methods are wrappers for the functionality of key construction, value transformation to a string (this value type is required for localStorage), and parsing.

The next three public methods are the most important elements of this class. It is setItem, getItem, removeItem that we will use most often. getKeys method is useful if you want to retrieve all keys associated with your application prefix. I added a parameter to decide if returned keys should have the prefix or not.

Now in your code you need to use the instance of this class.

localStorageService.setItem("user-settings", {theme: "dark", tableLimit: 10, windowSize: "medium"});

localStorageService.setItem("isSafetyModalOn", true);

const items = localStorageService.getItem("user-settings");
// "Items", { "theme": "dark", "tableLimit": 10, "windowSize": "medium" }

console.log('Storage keys', localStorageService.getKeys());
console.log('Storage keys with prefix', localStorageService.getKeys(true));

// "Storage keys",  ["user-settings", "isSafetyModalOn"]
// "Storage keys with prefix",  ["MY_APP_KEY-isSafetyModalOn", "MY_APP_KEY-user-settings"]

More advanced use of console logging

Michal M. — Sun, 16 Nov 2025 14:46:13 +0000

Logging values to the console is an integral part of my daily work (and probably yours too). We can place all sorts of messages in the console: validating data, displaying information after a process has completed, or providing developer warnings are just some of the uses of the console object.

All these operations and many more can be performed using only the methods available for this object. These include:

console.log
console.error
console.debug
console.info
console.warn

In this post, I'd like to present a more advanced way to manage logging in your application. This approach will bring order to your code and allow us to handle such a trivial operation with a separate module that we can modify as needed. In many projects, I've encountered the use of the no-console rule in ESlint, which resulted in scattered exceptions for this rule: // eslint-disable no-console. Thanks to the approach I've presented, this rule can be disabled in a single place in the code, because in the application, we won't be using the console object, but rather a dedicated class.

Preparation

First, let's start with interface and enum declarations.

interface LoggerInterface {
    debug: (message: string, data?: unknown) => void;
    info: (message: string, data?: unknown) => void;
    warning: (message: string, data?: unknown) => void;
    error: (message: string, error?: Error, data?: unknown) => void;
}


enum LogLevel {
    Debug,
    Info,
    Warning,
    Error,
}

Notice that I'm not using the any type—I've replaced it with the more specific unknown.
The next step is to declare the LogEvent helper class.

class LogEvent<T = unknown> {
    public readonly id = crypto.randomUUID();


    constructor(
        public readonly level: LogLevel,
        public readonly message: string,
        public readonly data?: T,
        public readonly error?: T
    ) {
        this.level = level;
        this.message = message;
        this.data = data;
        this.error = error;
    }
}

To assign the id, I use the crypto object available in the browser. This class is used to create the structure of the message object that we log to the console. This message will not only have a body. It will also contain additional information:

level - compatible with the LogLevel enum,
message - the actual message body,
data - data we can attach to the message,
error - if level is of type Error, this information will be attached to the object.

Finally, the most important class, which is used to gather information and use the appropriate method on the console object.

class Logger implements LoggerInterface {
    private readonly logToConsoleEnabled: boolean;


    constructor(logToConsoleEnabled: boolean) {
        this.logToConsoleEnabled = logToConsoleEnabled;
    }


    private logToConsole(event: LogEvent) {
        switch(event.level) {
            case LogLevel.Info:
                console.info(event.message, event);
            break;
            case LogLevel.Warning:
                console.warn(event.message, event);
            break;
            case LogLevel.Error:
                console.error(event.message, event);
            break;
            case LogLevel.Debug:
                console.debug(event.message, event);
            break;
            default:
                console.log(event.message, event);
        }
    }

    private log<T = unknown>(event: LogEvent<T>) {
        if (this.logToConsoleEnabled || event.level && event.level > LogLevel.Error) {
      this.logToConsole(event);
    }}


    private debug<T>(message: string, data: unknown): void {
        this.log(new LogEvent(LogLevel.Debug, message, data))
    }


    error<T>(message: string, error: T, data: unknown): void {
        this.log(new LogEvent(LogLevel.Error, message, data, error))
    }


    info<T>(message: string,  data: unknown): void {
        this.log(new LogEvent(LogLevel.Info, message, data))
    }


    warning<T>(message: string, data: unknown): void {
        this.log(new LogEvent(LogLevel.Warning, message, data))
    }
}

const logger = new Logger(true);

The class accepts only one parameter in its constructor, logToConsoleEnabled. This can be used to specify the environment in which notifications should be displayed in the console. A common use case is hiding logs in a production environment.

When using an instance of the class, we only use public methods, i.e., methods that use specific methods of the console object. Below are examples of displayed messages using this class.

Debug

logger.debug('Should return equation result', {valueX: 10, valueY: 20, result: 30});


"Should return equation result",  LogEvent: {
  "level": 0,
  "message": "Should return equation result",
  "data": {
    "valueX": 10,
    "valueY": 20,
    "result": 30
  },
  "error": undefined,
  "id": "2208fe54-ccbf-495e-81ae-81de1aea28e1"
}

Info


logger.info('User logged successfully', {user: {role: 'ADMIN'}});

"User logged successfully",  LogEvent: {
  "level": 1,
  "message": "User logged successfully",
  "data": {
    "user": {
      "role": "ADMIN"
    }
  },
  "error": undefined,
  "id": "983e9822-0e94-40fb-a4af-244e164e4e63"
}

Warning

logger.warning('This is warning!', {user: {name: 'John', age: 20}});

"This is warning!",  LogEvent: {
  "level": 2,
  "message": "This is warning!",
  "data": {
    "user": {
      "name": "John",
      "age": 20
    }
  },
  "error": undefined,
  "id": "0495d630-1917-4664-917b-5e35ce381e9b"
}

Error



logger.error('Not Authorized', {errorCode: 401}, {payload: null, userId: 29012});

"Not Authorized",  LogEvent: {
  "level": 3,
  "message": "Not Authorized",
  "data": {
    "payload": null,
    "userId": 29012
  },
  "error": {
    "errorCode": 401
  },
  "id": "3674e926-44d1-4fa8-a5c3-bd9a2e6c6187"
}

How to use infer keyword in Typescript

Michal M. — Mon, 20 Oct 2025 19:16:05 +0000

canonical_url: "https://www.geodev.me/blog/how-to-use-the-infer-keyword-in-typescript"

It's quite a rare part of Typescript and regular user won't encounter this during daily work. However it's useful part of the language and I would like to show you how you can use this functionality in your code.

infer is used exclusively within conditional types to extract a type from another type. It allows you to introduce a type variable that can be inferred (determined) by TypeScript's type checker during the conditional type evaluation. You should use infer primarily to destructure or deconstruct complex types into their constituent parts. This enables you to work with those individual parts to create new, more flexible, and reusable utility types.
If you have had contact with Typescript so far but mainly used simple types while declaring variables or interfaces - this topic may seem advanced and unclear (it was also mysterious for me).

Let's move on to examples.

Extracting the Element type from an array

type ArrayElement<T> = T extends (infer E)[] ? E : T;

type Numbers = ArrayElement<number[]>; // 'number'
type StringElements = ArrayElement<string[]>; // 'string'
type NonArray = ArrayElement<boolean>; // 'boolean'

What's the logic here? ArrayElement checks if T is an array. If it is, infer E extracts the element type into a new type variable E, which is then returned. Otherwise, it returns T.

Extracting the Return type of a function

This example shows how to redo a ReturnType which is already a part of a language. Rewriting this functionality will help you to understand how infer works.

type GetReturnType<T> = T extends (...args: any[]) => infer R ? R : never;

const add = (a: number, b: number) => a + b;
type AddResult = GetReturnType<typeof add>; // 'number'

type VoidFuncResult = GetReturnType<() => void>; // 'void'
type NotFunc = GetReturnType<string>; // 'never'

Created type checks if T is a function that takes any arguments (...args: any[]) and returns any value. If it matches, infer R captures the return type, which is then returned.

Extracting the Resolved Type from a Promise (Awaited)

The next example is also a custom implementation of existing language functionality. Here's the simplified version of Awaited. Here I used PromiseLike<T> which is an interface that represents any object that has a then method.

type UnwrapPromise<T> = T extends PromiseLike<infer U> 
    ? UnwrapPromise<U>
    : T;

type SimplePromise = UnwrapPromise<Promise<number>>; // 'number'
type NestedPromise = UnwrapPromise<Promise<Promise<string>>>; // 'string'
type RegularType = UnwrapPromise<boolean>; // 'boolean'

This solution checks if T is a Promise. If it is, infer U captures the resolved type. It then recursively calls UnwrapPromise<U> to handle nested promises (e.g., Promise<Promise<number>>). If not a Promise, it returns T.

The examples I provided should meet most needs in everyday TS work. I have seen much more advanced examples of this use in various projects, but it mainly concerned local libraries development.

Operations Order with Asynchronous JavaScript

Michal M. — Fri, 20 Jun 2025 20:48:29 +0000

Once every few months I do a "retest" of my JavaScript knowledge. I review sets of recruitment questions and refresh fundamentals of this language. One of the most important topics that I always review is the Event Loop. In short: it's the mechanism that allows JavaScript, despite being single-threaded, to handle asynchronous operations without blocking the main execution thread.

Because of this many of our daily problems are focused on solving the valid order of synchronous and asynchronous operations we have in our programs. That being said examples like this below and similar are quite popular during the recruitment process. At least I had this topic for a few times. I don't want to focus on explaining this problem in detail. It has already been sufficiently described in many articles by people who have much more knowledge and experience than me.

So what's the correct order of logs that will show up in the console?

console.log('First');

setTimeout(() => {
    console.log('Second');
}, 0);

new Promise((res) => {
    res('Third');
}).then(console.log);

console.log('Fourth');

The answers is:

First

Fourth

Third

Second

Now the explanation. While one might intuitively expect the output to be "First", "Second", "Third", "Fourth" due to the sequential reading of the code, JavaScript's asynchronous nature dictates a different order. The setTimeout with a 0ms delay and the Promise.then callback are not executed immediately after they are encountered. Instead, they are placed into different queues and processed by the event loop at specific times.

First console.log is a synchronous operation and is pushed on the top of the Call stack and immediately executed.

setTimeout is an asynchronous Web API and these operations will execute after the synchronous top-level functions. It's scheduled to be placed in the Callback Queue (Macrotask Queue) after the timer expires (which is almost immediately, but still after the current synchronous execution finishes).

Promise is a part of Microtask Queue. These are handled with higher priority than Macrotasks. Once the current synchronous code finishes and the promise is resolved (which it already is), we will get the 'Third' logged in the console.

The last line with console.log is another synchronous operation. It's immediately pushed onto the Call Stack and executed.

To sum up, the general order of operations is:

Run all synchronous code on the Call Stack.
Drain the entire Microtask Queue. (Promise, MutationObserver)
Take one task from the Macrotask Queue and execute it. (setTimeout, setInterval)
Repeat from step 1.

Implementing zen mode in React

Michal M. — Wed, 29 Jan 2025 19:30:16 +0000

Zen mode is a popular UX pattern that creates a distraction-free experience for application users. It's a simple approach where part of application interface is hidden on user's demand. I have encountered this mode in applications where the main functions are based on focus and tranquility. One of them is Lichess, the second chess platform in the World. I am a chess enthusiast and I am trying (with poor results) to develop my skills in this direction. If you're a chess enthusiast too, feel free to challenge me to a game.
Lichess has a Zen mode, and I thought I'd write a post about how you can implement it in your own React app.

Setup

First we need a markup to create our layout. I've decided to copy some of the Lichess approach which is close to the Holy Grail. If you don't know what a Holy Grail in web design is, start with Wikipedia. Here's how it looks like in my example:

To achieve this I used css grid.

import './App.css'


function App() {
  return (
    <div className="container">
      <div className="box top">Top Section</div>
      <div className="box right">Right Section</div>
      <div className="box main">Main Section</div>
      <div className="box left">Left Section</div>
      <div className="box bottom">Bottom Section</div>
    </div>
  )
}


export default App

And below is the css portion of this design (App.css).

.box {
  border: 1px solid #47a5bd;
}


.container {
  display: grid;
  grid-template-columns: 100px 1fr 100px;
  grid-template-rows: auto 1fr auto;
  grid-template-areas:
  "top top top"
  "right main left"
  "bottom bottom bottom";
  gap: 10px;
  height: 100%;
}


.top {
  grid-column: 1 / span 3;
  grid-row: 1;
  height: 100px;
  grid-area: top;
}


.right {
  grid-column: 3;
  grid-row: 2;
  grid-area: right;
}


.left {
  grid-column: 1;
  grid-row: 2;
  grid-area: left;
}


.main {
  grid-column: 2;
  grid-row: 2;
  grid-area: main;
  border: 1px solid lightblue;
  background-color: #74756d;
}


.bottom {
  grid-column: 1 / span 3;
  grid-row: 3;
  height: 100px;
  grid-area: bottom;
}

In this example, enabling zen mode will hide all containers except the center one with the class "main".

User interaction

To turn on the Zen Mode we need a interaction handler. I decided to turn this feature on/off with the "Z" key. To handle this I created a hook which can be reused in any other components in the application.

import { useCallback, useEffect } from "react";


export const useKeyboardShortcut = (keyShortcut: string, callback: (event: KeyboardEvent) => void) => {


  const handleKeydown = useCallback((event: KeyboardEvent) => {
    if (keyShortcut === event.key) {
      callback(event)
    }
  }, [keyShortcut, callback]);


  useEffect(() => {
    window.addEventListener('keydown', handleKeydown);


    return () => {
      window.removeEventListener('keydown', handleKeydown);
    }
  }, [handleKeydown]);
}

I deliberately left this hook very simple. It can take a single key as an argument and callback to trigger after the key is pressed. In modern web applications you can use many more complex keyboard shortcuts, but that is beyond the scope of this article. All we need here is to listen for a keydown event and react to it. Next, we have to use this hook in App.tsx.

import './App.css'


function App() {
  useKeyboardShortcut('z', () => console.log('Callback'));

  return (
    <div className="container">
      <div className="box top">Top Section</div>
      <div className="box right">Right Section</div>
      <div className="box main">Main Section</div>
      <div className="box left>Left Section</div>
      <div className="box bottom">Bottom Section</div>
    </div>
  )
}


export default App

We have to pass a callback function that will trigger on the 'z' key. For now put just console.log and check if there's log in the browser's console if you press 'z' key.

Store the zen mode state

There are a few methods of storing the state of the user's UI. Lichess stores this information in the database, so there's a request made if user toggles this option. I decided to store this information in the browser. I think that zen mode is a temporary option and there is no need to make a request to the backend. I also chose this option because my demo application does not have a backend ;-). So in this example I will show how to store the information in the URL. Furthermore, maintaining application state in the URL is a popular method in React apps.

To do it I created another hook. It gets the search parameters from the URL and handles the changes. To demonstrate the underlying mechanics, I opted not to use react-router in this example. Besides I achieved this by using URLSearchParams interface from Web API.

I know that react-router is a standard library to support this type of operations. I believe that sometimes it is worth taking a step back and checking how to use the basic tools provided by the browser API.

import { useEffect, useState } from "react"


export const useUrlParams = () => {
  const [params, setParams] = useState<URLSearchParams>();


  const handleUpdateUrl = (params?: URLSearchParams) => {
    if (typeof window === 'undefined') return

    const newParams = new URLSearchParams(params?.toString());
    const queryString = newParams?.toString();
    const newUrl = queryString ? `${window.location.pathname}?${params?.toString()}` : window.location.pathname;
    window.history.replaceState(null, "", newUrl);
    setParams(newParams);
  }


  useEffect(() => {
    if (typeof window !== 'undefined') {
      const searchParams = new URLSearchParams(window.location.search)
      setParams(searchParams)
    }
  }, [])


  return {
    params,
    handleUpdateUrl,
  }
}

useUrlParams hook synchronizes the URL's search parameters with the component's state and provides a utility function for updating the URL programmatically. It returns two values:

params: The current URLSearchParams object, representing the query parameters,
handleUpdateUrl: A function to modify the URL's query parameters.

To make this hook useful we need another hook (the last one) for toggling the zen mode.

Toggle the zen mode

The useZenMode hook is a react hook designed to manage a Zen Mode state using URL query parameters. It builds upon the useUrlParams hook to dynamically toggle and reflect the Zen Mode state in the browser's URL. If you want to store this information in other way (localStorage, sessionStorage, etc.), you have to change the handleSwitchZenMode function implementation.

import { useUrlParams } from "./useUrlParams";


export const useZenMode = (paramName = 'zenMode') => {
  const {params, handleUpdateUrl} = useUrlParams();
  const zenMode = params?.get(paramName) === "true" || false;


  const handleSwitchZenMode = () => {
    const newMode = !zenMode;
    if (newMode) {
      params?.set(paramName, newMode.toString());
    } else {
      params?.delete(paramName);
    }
    handleUpdateUrl(params);
  }


  return {
    zenMode,
    handleSwitchZenMode
  }
}

The last part is to join the hooks together in the main component.

Conclusion

Here's the final version of the App.tsx component that combines useZenMode and useKeyboardShortcut hooks. Also I've added conditional css classes to reflect the changes in the UI.

import './App.css'
import { useKeyboardShortcut } from './hooks/useKeyboardShortcut'
import { useZenMode } from './hooks/useZenMode';


function App() {
  const {zenMode, handleSwitchZenMode} = useZenMode();
  useKeyboardShortcut('z', handleSwitchZenMode);


  return (
    <div className="container">
      <div className={`box top ${zenMode ? 'hidden' : ''}`} aria-hidden={zenMode}>Top Section</div>
      <div className={`box right ${zenMode ? 'hidden' : ''}`} aria-hidden={zenMode}>Right Section</div>
      <div className="box main">Main Section</div>
      <div className={`box left ${zenMode ? 'hidden' : ''}`} aria-hidden={zenMode}>Left Section</div>
      <div className={`box bottom  ${zenMode ? 'hidden' : ''}`} aria-hidden={zenMode}>Bottom Section</div>
    </div>
  )
}


export default App

I added css classes to all containers that I want to hide with zen mode. The class hidden changes the visibility property from unset to hidden. I've chosen this option to prevent the layout shifting which might occur if you use display: none.

.hidden {
  visibility: hidden;
}

Finally, here's how it looks like in action.

Typescript: Conditional types

Michal M. — Thu, 26 Dec 2024 13:57:09 +0000

Writing conditions in our code is one of the most utilized functionalities of the programming languages we are writing in. Even though I've been using Typescript for several years now I did not realize that it allows me to write conditional types. I find it one of the most unique features of the Typescript so far.

For some use cases in our code we cannot declare the particular type yet (like string or number). This is a situation where conditional types comes in handy.
Thanks to this feature we can write instructions like:

Declare the type T which is dependent on type K (or other types as well). If K equals to string, declare type A, otherwise declare type B.

This can be represented with this naive examples:

// 1.
type CheckType<T> = T extends string ? 'is string' : 'not string';

type ResultType1 = CheckType<'type'>; // 'is string'
type ResultType2 = CheckType<101>; // 'not string'

// 2.
type IsTypeString<T> = T extends string ? true : false;

type Check1 = IsTypeString<'mike'>; // true
type Check2 = IsTypeString<222>; // false

We can break down these examples into steps:
1) CheckType type is declared with a generic T. This part answers the question: "Is the T type a subtype of a string?",
2) If yes, then the type will be is string (exact string value) or true, otherwise choose the second option from the ternary.

As you can see in the examples above the syntax of the condition is the same as the regular JavaScript ternary operators. They can be nested as well.

Let's go a step further. There is a difference in how Typescript distribute union types. Below are two similar ways to declare a type for an array.

// Type union
type ToArray<T> = T[];

type A_1 = ToArray<number>;
type B_1 = ToArray<string | number>; // (number | string)[]

const firstArray: B = [1,2,3, "2"];

// Conditional type
type ToArraySecond<T> = T extends unknown ? T[] : T[];

type A_2 = ToArraySecond<number>;
type B_2 = ToArraySecond<string | number>; // number[] | string[] (!)

const secondArray: B_1 = [1,2,3, "2"] // Ts error

If we use conditional type in the second example, Typescript creates two different branches of possible types.

Conditional types is not something you come across often. I find it to be another useful tool to solve our daily problems when writing code.

Spread the object and omit keys

Michal M. — Thu, 17 Aug 2023 17:10:44 +0000

Lastly I needed to create a shallow copy of an object but omit some keys. To make the code more compact I didn't want to use the delete operator. ES6 spread operator allows to do it.

Below is an example original object. I want to copy it but omit the city and country keys.

const user = {
    age: 20,
    name: 'Garry',
    city: 'Copenhagen',
    country: 'Denmark'
};

const { city, country, ...userCopy } = user;

console.log(userCopy);

/**
{
    "age": 20,
    "name": "Garry"
}
**/

However, this solution creates new, unused variables (city and country) with their values:

console.log(city) // 'Copenhagen'
console.log(country) // 'Denmark'

Ideally we don't want to create any side effects. Here's the solution.

function omitKeys(keys, obj) {
    const excluded = new Set(keys);
    return Object.fromEntries(Object.entries(obj).filter(e => !excluded.has(e[0])))
}

console.log(omitKeys(['city, country'], user));
/**
{
    "age": 20,
    "name": "Garry"
}
**/

console.log(city) // city is not defined;
console.log(country) // country is not defined;

Discriminated unions in Typescript

Michal M. — Sat, 08 Jul 2023 18:01:14 +0000

Discriminated unions, also known as tagged unions or algebraic data types, are a feature in TypeScript that enable developers to model and work with varying types of data in a concise and type-safe manner. They provide a way to define a type that can represent multiple alternatives, where each alternative has a unique discriminant property to differentiate it from the others. This discriminant property acts as a type guard, allowing the TypeScript compiler to narrow down the type and provide more accurate type inference.

By using discriminated unions, developers can create expressive and self-describing types that accurately capture the possible states or variants of a value. This is particularly useful when dealing with scenarios such as handling different response types from API calls, representing different error conditions, or modeling complex data structures with varying shapes.

I would like to show how we can implement such types. I had a chance to implement it while working on a API architecture in one of my side-projects.
So we have an API response that might have two results: success and error (rejected state). Both response have some common fields, but they also differ.
If a request succeed we will receive a data in some kind of shape. If a request fails we will receive an error message.
First, let's type the generic API response:

type SuccessResponse<T> = { status: 'success', data: T, time: Date };
type ErrorResponse = { status: 'error', message: string, time: Date };
type RequestResponse<T> = SuccessResponse<T> | ErrorResponse;

I used generic here to describe the data if we have a success request. Now let's create a mock response for each of the states.
At the top of the file I created a type for the specific data we're requesting.

type ResponseType = {
  users: string[];
  total: number;
};

const successResponse: RequestResponse<ResponseType> = {
  status: 'success',
  data: {
    users: ['Mark', 'Sophie', 'Pavel'],
    total: 3,
  },
  time: new Date(),
}

const errorResponse: RequestResponse<ResponseType> = {
  status: 'error',
  message: 'Comprehensive error message',
  time: new Date(),
}

Depending on the status property, the appropriate branch of the conditional statement is executed, providing a clear and concise way to handle different response types.
Using discriminated unions in this scenario allows us to effectively handle different API response types with type safety and readability.

Customizing Errors in JavaScript

Michal M. — Sun, 04 Jun 2023 11:44:17 +0000

Error handling is a critical aspect of software development, enabling developers to identify and resolve issues efficiently. JavaScript provides the Error class as a foundation for creating and customizing error objects, allowing developers to create tailored error messages, add additional information, and handle exceptions effectively. In this article, I would like to shou you how the Error class can be utilized to enhance error handling in JavaScript applications.

In JavaScript, the Error class serves as the base class for all error-related objects, including built-in error types like SyntaxError, ReferenceError, and TypeError. By extending the Error class, we can create their own custom error types that encapsulate specific scenarios or domain-specific errors.

Creating custom Error types

It's simple. We have to define a new class that extends the Error class.

First I like to define available error types so I have an ordered and defined set of Error options:

export const ERROR_TYPES = {
  CLIENT: 'CLIENT_ERROR',
  SERVER: 'SERVER_ERROR',
  RUNTIME: 'RUNTIME_ERROR',
} as const;

type EnumValues<T> = T[keyof T];

export type ErrorTypes = EnumValues<typeof ERROR_TYPES>;

export interface IError {
  message: string;
  type: ErrorTypes;
}

If my application will require a new error type to handle, I will start defining it from this file. Note that I don't use enum . I rather create a POJO to define my reusable set of data. I described it in one of my previous articles.

Now I create a separate class for my new custom Error:

import { ERROR_TYPES, ErrorTypes } from '@errors/types';

class ClientError extends Error {
  name: ErrorTypes;
  constructor(message: any) {
    super(message);

    if (Error.captureStackTrace) {
      Error.captureStackTrace(this, ClientError);
    }

    this.name = ERROR_TYPES.ClientError ;
    console.error(`${ERROR_TYPES.ClientError } - ${message}`);
  }
}

export default ClientError;

In the above example, I extend the Error class and assign a name property to the custom error class, allowing us to identify the specific error type.

Once I have defined my custom error class, we can create instances of it and throw them using the throw keyword or return the class instance with message and other information we want to include in our error handler. Throwing a custom error enables us to provide meaningful error messages and additional context to aid in debugging.

I like to create couple of Errors classes and use them depending on the purpose. To utilize this idea, I create a function to distinguish errors:

import ClientError from '@errors/ClientError';
import AuthorizationError from '@errors/AuthorizationError ';
import ServerError from '@errors/ServerError';
import OtherErrorfrom '@errors/OtherError';

export const errorHandler = (error: any, actionType: string) => {
 if (error.response.status === 401) {
     return new AuthorizationError(`${actionType} - ${error.message}`);
 } else if (error.response.status < 500 && error.response.status >= 400) {
     return new ClientError(`${actionType} - ${error.message}`);
 } else if (error.response.status >= 500) {
     return new ServerError(`${actionType} - ${error.message}`);
 } else {
     return new OtherError(`${actionType} - ${error.message}`);
 }
};

Usage

Consider fetching the data. It's a very error-prone operation. If you have a well written and solid architecture for fetching data, it should be easy to implement Error module inside it. Below is a common pattern that I encountered in few applications I was working on.

const fetchData = async () => {
    try {
      return await fetchLocationData();
    } catch (err) {
      errorHandler(err, '[fetchLocationData]');
    }
};

If the fetching data function (fetchLocationData) will return a 400 error, I will receive the following information in the console:

ERROR: "CLIENT ERROR - [fetchLocationData] - // Rest of message thrown from operation"

With our error handling module, it's easier to find where the error was thrown or what particular method have thrown it. What's more, we can catch the error and use it in other place of our application. For example while displaying the error to the user, we can include the error details. The end user can report the error to you giving you the information you need - the error code, the message, the name of the method that returned this error.

Conclusion

The Error class in JavaScript provides a powerful mechanism for customizing and extending error handling capabilities. By creating custom error types, developers can craft error messages tailored to their applications and domain-specific scenarios. Leveraging the Error class empowers developers to improve the reliability and maintainability of their JavaScript code by enhancing error reporting and enabling more effective debugging.

Something about Typescript enums

Michal M. — Thu, 27 Apr 2023 14:38:55 +0000

Enums let us to define a set of named constants. It's essentially a set of key-value pairs, where the keys are string or numeric values that represent a set of related constants.

The simpliest example is:

enum UserRoles {
    ADMIN,
    USER,
    GUEST
}

If we don't set the value, Typescript will automatically add it for you. Each value is assigned a numeric value starting from 0.

enum UserRoles {
    ADMIN = 0,
    USER = 1,
    GUEST = 2
}

When you define an enum in TypeScript, the TypeScript compiler generates code that defines a JavaScript object with the same name as the enum. The object has properties for each enum member, which are set to the corresponding numeric value. The names of the enum members are not included in the generated JavaScript code. The example above will compile to following JavaScript code:

var UserRoles;
(function (UserRoles) {
    UserRoles[UserRoles["ADMIN"] = 0] = "ADMIN";
    UserRoles[UserRoles["USER"] = 1] = "USER";
    UserRoles[UserRoles["GUEST"] = 2] = "GUEST";
})(UserRoles || (UserRoles = {}));

Note that the enum definition also defines a reverse mapping, where the numeric value of an enum member can be used to look up its name. So we can access enum values by it's index and get enum keys:

const user = UserRoles[1];
console.log('User Roles', user); // "User Roles",  "USER"

To sum up, here's the final shape of our UserRoles enum:

 console.log(UserRoles);
 // Result:
 {
  "0": "ADMIN",
  "1": "USER",
  "2": "GUEST",
  "ADMIN": 0,
  "USER": 1,
  "GUEST": 2
}

Caveats

Here is the example which shows that using enum might be unpredictable or dangerous:

if (UserRoles.Admin) {
    // ...logic
}

If we don't set string value to this enum, this code won't be accessible because

UserRoles.Admin returns false.

Another example shows how weird the enum is interpreted by the Typescript itself.

enum UserRoles {
    ADMIN = 'ADMIN,'
    USER = 'USER',
    GUEST = 'GUEST',
}

function getUserRole(role: UserRoles) {
    // ...
}

getUserRole(UserRoles.Admin) // No Error
getUserRole('ADMIN'); // Error!

The second function call will throw a TS error:
Argument of type '"ADMIN"' is not assignable to parameter of type 'UserRoles'.(2345)

So it's not possible to use a value which is not expressed by the enum itself.

const enums

That's the enum modifier that won't compile to JavaScript. So const enum will exist only in Typescript world.

enum UserRoles {
    ADMIN = 'ADMIN,'
    USER = 'USER',
    GUEST = 'GUEST',
}

When you use a const enum in your TypeScript code, the compiler replaces all references to the enum with the actual values at compile-time. This means that there is no generated code for the const enum, and it is not included in the compiled JavaScript output. So a const enum member can only be accessed using a string literal. There are few limitations also:

Const enums can only have constant enum members, and cannot have computed or aliased values.
Const enums cannot be used in a context where a type is expected, such as in a function signature or type annotation.

However, the Typescript Handbook will tell you, that you probably don't want to use const enum. If the authors of a given technology are telling you that some part of their tool should not be used - probably it's a good idea to stick with that advice.

What instead of Enum?

Using a POJO with a Typescript features is a good replacement for enums.

const USER_ROLES= {
    ADMIN: 'ADMIN',
    USER: 'USER',
    GUEST: 'GUEST',
} as const;

type EnumValues<T> = T[keyof T];

type UserRoles = EnumValues<typeof USER_ROLES>;

function getUserRole(role: UserRoles) {
    // ...
}

getUserRole('ADMIN') // No Error
getUserRole(USER_ROLES.ADMIN) // No Error

This requires a few more Typescript lines to extract the keys and values from the USER_ROLES. But it gives a expected and natural way to use the predefined object with values.

Type-check react-i18next translation keys

Michal M. — Fri, 13 Jan 2023 19:02:18 +0000

Enums let us to define a set of named constants. It's essentially a set of key-value pairs, where the keys are string or numeric values that represent a set of related constants.

The simpliest example is:

enum UserRoles {
    ADMIN,
    USER,
    GUEST
}

If we don't set the value, Typescript will automatically add it for you. Each value is assigned a numeric value starting from 0.

enum UserRoles {
    ADMIN = 0,
    USER = 1,
    GUEST = 2
}

var UserRoles;
(function (UserRoles) {
    UserRoles[UserRoles["ADMIN"] = 0] = "ADMIN";
    UserRoles[UserRoles["USER"] = 1] = "USER";
    UserRoles[UserRoles["GUEST"] = 2] = "GUEST";
})(UserRoles || (UserRoles = {}));

Note that the enum definition also defines a reverse mapping, where the numeric value of an enum member can be used to look up its name. So we can access enum values by it's index and get enum keys:

const user = UserRoles[1];
console.log('User Roles', user); // "User Roles",  "USER"

To sum up, here's the final shape of our UserRoles enum:

 console.log(UserRoles);
 // Result:
 {
  "0": "ADMIN",
  "1": "USER",
  "2": "GUEST",
  "ADMIN": 0,
  "USER": 1,
  "GUEST": 2
}

Caveats

Here is the example which shows that using enum might be unpredictable or dangerous:

if (UserRoles.Admin) {
    // ...logic
}

If we don't set string value to this enum, this code won't be accessible because

UserRoles.Admin returns false.

Another example shows how weird the enum is interpreted by the Typescript itself.

enum UserRoles {
    ADMIN = 'ADMIN,'
    USER = 'USER',
    GUEST = 'GUEST',
}

function getUserRole(role: UserRoles) {
    // ...
}

getUserRole(UserRoles.Admin) // No Error
getUserRole('ADMIN'); // Error!

The second function call will throw a TS error:
Argument of type '"ADMIN"' is not assignable to parameter of type 'UserRoles'.(2345)

So it's not possible to use a value which is not expressed by the enum itself.

const enums

That's the enum modifier that won't compile to JavaScript. So const enum will exist only in Typescript world.

enum UserRoles {
    ADMIN = 'ADMIN,'
    USER = 'USER',
    GUEST = 'GUEST',
}

Const enums can only have constant enum members, and cannot have computed or aliased values.
Const enums cannot be used in a context where a type is expected, such as in a function signature or type annotation.

What instead of Enum?

Using a POJO with a Typescript features is a good replacement for enums.

const USER_ROLES= {
    ADMIN: 'ADMIN',
    USER: 'USER',
    GUEST: 'GUEST',
} as const;

type EnumValues<T> = T[keyof T];

type UserRoles = EnumValues<typeof USER_ROLES>;

function getUserRole(role: UserRoles) {
    // ...
}

getUserRole('ADMIN') // No Error
getUserRole(USER_ROLES.ADMIN) // No Error

This requires a few more Typescript lines to extract the keys and values from the USER_ROLES. But it gives a expected and natural way to use the predefined object with values.

Own reduce method using Typescript

Michal M. — Mon, 27 Jun 2022 20:05:28 +0000

In my previous post I presented my approach to implement my own versions of some higher order functions in JavaScript. I covered three of them and one, a very powerful one was missing.
The Array.prototype.reduce.

In this short post, I'd like to show you my take on this higher order function using Typescript.

First, let's extend the Array prototype types. That's the part I'm not sure of. The Typescript compiler does not complain, but I feel that's something's wrong here. If you know what, let me know.

interface Array<T> {
    myReduce(cb: (previousValue: T, currentValue: T, index: number, array: T[]) => T, initialValue: T): T;
}

And the function itself should look like this:

Array.prototype.myReduce = function<ReducedElem, ReducedValue>(callback: (previousValue: ReducedValue, currentValue: ReducedElem, index: number, array: ReducedElem[]) => ReducedValue, initialValue: ReducedValue): ReducedValue {
    let i = 0;
    let reduced = initialValue;

    if (arguments.length < 2) {
        i = 1;
        reduced = this[0];
    }
    for (i = 0; i < this.length; i++) {
        reduced = callback(reduced, this[i], i, this)
    }

    return reduced;
}

I've tested this solution with a few examples.

// Classic usage - sum the numbers in the array
const numbers = [1, 10, 100, 1000];
numbers.myReduce((sum, curr) => sum + curr, 0) // Result: 1111

// Find the most recent date
const dates = [
  '1999/01/01',
  '2022/12/01',
  '2010/05/01',
  '2022/01/01'
];
dates.myReduce((max, curr) => curr > max ? curr : max, dates[0]) // Result: '2022/12/01'

// Flatten an array
const persons = [['Andrew', 'Joe'], ['Margaret', 'Sylvia'], ['Andrew', 'Rebecca', 'Joe', 'Sylvia']];
persons.myReduce((flatArray, currArray) => flatArray.concat(currArray), [])
/* [
      'Andrew', 'Joe', 'Margaret', 'Sylvia', 'Andrew', 'Rebecca', 'Joe', 'Sylvia'
   ]
*/

These examples work fine and gave me the expected results. The Typescript compiler is not complaining about these examples as well.
For more information about typing function I recommend to get familiar with a Functions chapter on the Typescript official site.