Forem: Jakub Švehla

Rethink JS Classes: Embrace Closures for Lightweight State & Typing

Jakub Švehla — Sun, 06 Apr 2025 12:00:00 +0000

Hey devs,

Let’s talk about classes. Or rather — let’s talk about not using them probably?

JavaScript gives us powerful tools like closures and lexical scope, yet we often fall back on class-based patterns borrowed from Java or C#. While classes have their place — especially when true inheritance or complex hierarchies are needed — they come with baggage: extra syntax, confusing this, and often heavier abstractions than necessary.

Instead, I want to show you a more lightweight, idiomatic JS/TS approach: builder functions powered by closures.

🎯 Why Closures over Classes?

Closures give you all the essentials — without the class boilerplate:

✅ Perfect type inference — TypeScript just gets it
✅ Encapsulation without needing private or # fields
✅ Lightweight state management — scoped variables instead of this.state
✅ No this, no .bind() — just function context
✅ Feels natural for React devs — if you're used to thinking in hooks and closures, this pattern feels like home even outside React (Node.js, libraries, CLI tools...)
✅ Easily composable functions — compose and reuse functions to create complex behaviors effortlessly

Think of it as “just enough OOP” without all the baggage.

👶 Example: Basic Instance

const RethinkedClass = (constructorArgInitCounter?: number) => {
  // mutable variable
  let state = { counter: constructorArgInitCounter ?? 0 }

  // private state (pointer to privateState is not returned
  let privateState = { private: 'state' }

  // methods
  const increase = () => state.counter++

  // public facing API
  return { state, increase }
}

const instance1 = RethinkedClass(10)
const instance2 = RethinkedClass()
instance1.increase()
instance1.increase()
instance2.increase()
console.log(instance1.state.counter, instance2.state.counter) // 12, 1

You get two separate instances, each with its own internal counter and no this weirdness.

🧠 Type Inference Magic

One of the most powerful features of this functional approach is that TypeScript understands the return types automatically.

You don’t have to write out complex class definitions, manually maintain this context, or even define interfaces unless you want to.

Let TypeScript infer everything for you — even for deeply nested structures.

const ComplexClass = (name: string) => {
  let state = {
    counter: 0,
    meta: {
      createdAt: new Date(),
      createdBy: name,
    },
    tags: ['tag1']
  }

  const increase = () => state.counter++
  const addTag = (tag: string) => state.tags.push(tag)

  return {
    state,
    increase,
    addTag,
    reset: () => {
      state.counter = 0
      state.tags = []
    }
  }
}

const instance = ComplexClass('devto_user')

instance.increase()
instance.addTag('fun')
instance.addTag('typescript')
console.log(instance.state)
// auto-completion works perfectly!

No need to define types or interfaces — unless you want to.
Full autocomplete and type safety in IDEs.
Cleaner code, no boilerplate classes, constructors, or properties.
TypeScript infers exact structure, including methods, nested objects, arrays, and types. > This pattern scales — the more complex your internal state becomes, the more you benefit from automatic inference.

🧍‍♂️ Singleton Instance

const singletonRethinkedClass = (() => {
  let state = { counter: 0 }
  const increase = () => state.counter++
  return { state, increase }
})()

singletonRethinkedClass.increase()
singletonRethinkedClass.increase()
console.log(singletonRethinkedClass.state.counter) // prints 2

This pattern is also known as an IIFE – Immediately Invoked Function Expression.

No class, no new, no prototype, no __proto__ just pure JS — scoped and stateful.

📐 Interfaces

Interfaces? just use satisfies instead

type SomeRandomClassInterface = {
  counter: number,
  increase: () => number
}

const MyClass = (constructorArgInitCounter?: number) => {
  const counter = constructorArgInitCounter ?? 1
  const increase = () => counter++
  return { counter, increase } satisfies SomeRandomClassInterface
}

Boom, typed with satisfaction 😎.

problems with understanding `.prototype.` or `proto`?

Nope. Nothing like that here. Just Function scopes and a few stable pointers on top of it.

🔗 Namespaced Static Methods with Cross-References

Another great benefit of this pattern is how naturally it supports functions that depend on each other — all scoped in the same closure.

export const myModule = (() => {
  const fn1 = () => {
    console.log('Hello from fn1')
    return 42
  }

  const fn2 = () => {
    const result = fn1()
    console.log('fn2 called fn1 and got:', result)
  }

  return { fn1, fn2 }
})()

myModule.fn2()
// Output:
// Hello from fn1
// fn2 called fn1 and got: 42

This is a clean, composable pattern that:

Keeps related logic together
Prevents leaking internal helpers outside
Avoids circular imports
Keeps everything testable, typed, and encapsulated

You can think of it as a "scoped mini-module" — great for feature modules, utils, services, or domain logic.

😵‍💫 Binding `this`?

Ever had to bind(this) because this got lost in the callback wilderness?

class A {
  state = 0
  hello() {
    console.log(this.state)
  }
}
const aInstance = new A()
aInstance.state = 10
const helloPointer = aInstance.hello.bind(aInstance) // You need to do a bind this, or this code will no work at all
helloPointer() // print 10

Now compare with this scoped alternative:

const A = () => {
  const state = { counter: 0 }
  return {
    state,
    hello: () => {
      console.log(state.counter )
    }
  }
}
const aInstance = A()
aInstance.state.counter = 10
const helloPointer = aInstance.hello // works without bind!
helloPointer() // prints 10

Scoped closures never lose their context. That's the real magic.

🏗️ Class Builder

this is an alternative way how to solved some problems, which are normally solved by inheritance

const classGenerator = (name: string) => {
  return (constructorArg) => {
    const state = { counter: 0, name }

    const increase = () => state.counter++

    return {
      state,
    }
  }
}
const MyClassA = classGenerator('a')
const MyClassB = classGenerator('b')

const a = MyClassA()
const b = MyClassB()
console.log(a.state.name) // prints a
console.log(b.state.name) // prints b

Currying, composition, and encapsulation with just functions.

✅ Benefits

Type inference works perfectly – it's just a function.
No this pain or need for .bind()/.call().
Inheritance is literal – just spread or compose.

🧨 Possible downsides?

you need to wrap basic values like boolean/number/string to an object to get an pointer instead of copying values
You're creating a lot of instances of functions (methods) in a memory.
You can't use instanceof easily – but that's OK if you're doing type-driven development.

Give it a try, refactor one class, and feel the freedom of just writing functions.

Classes are just sugar, and you don’t need that in your coffee ☕.

Let me know what you think or share your own scoped-class trick in the comments 👇

🧰 Bonus: Context Builder with AsyncLocalStorage

Let’s finish strong with a real-world pattern using this functional style — a generic AsyncLocalStorage context builder.

Instead of OOP-style context managers, we use a simple higher-order function with full type inference:

import { AsyncLocalStorage } from 'node:async_hooks'

export const genericAsyncLocalStorageContextBuilder = <InitState, T>(
  stateFn: (initState: InitState) => T
) => {
  const storage = new AsyncLocalStorage<T>()

  return {
    provideContext: (initState: InitState, callback: () => Promise<void> | void) => {
      const contextValue = stateFn(initState)
      return storage.run(contextValue, callback)
    },
    useContext: () => {
      const store = storage.getStore()
      if (!store) {
        throw new Error('❌ No context available. Make sure to use .run() before accessing the context.')
      }
      return store
    },
  }
}

✅ How to use it


const loggerContext = genericAsyncLocalStorageContextBuilder(() => {
  const state = { 
    counter: 0
  }

  return {
    state,
    increase: () => state.counter++
  }
})

🧲 Bonus #2: Reference Serializer with Internal WeakMap

Need to track object references and assign them unique serializable IDs?

Here's a clean, testable, and zero-boilerplate way to do it — again, no class needed.

const serializeRef = (() => {
  const referenceMap = new WeakMap<object | ((...args: unknown[]) => unknown), number>()
  let counter = 0

  const get = (obj: object | ((...args: unknown[]) => unknown)) => {
    // You can add type guards here if needed
    if (!referenceMap.has(obj)) {
      referenceMap.set(obj, counter++)
    }
    return referenceMap.get(obj)!
  }

  return {
    get,
  }
})()

✅ How to use it

const refSerializer = buildSerializeRef()

const objA = {}
const objB = {}

console.log(refSerializer.get(objA)) // 0
console.log(refSerializer.get(objB)) // 1
console.log(refSerializer.get(objA)) // 0 (same as before)

This utility:

Uses a closure for state (referenceMap, counter)
Exposes a simple, focused API (get)
Avoids global side effects
Is easily mockable & testable
Is perfect for serialization, diffing, or memoization

TypeScript or F#?!? WHICH IS BETTER?!

Jakub Švehla — Tue, 15 Feb 2022 21:51:43 +0000

Today I'll try to compare two different programming languages, F# and TypeScript.
Both of them are multiplatform, high-level, and statically-typed so we're able to use them to write any kind of type-safe application like web-servers, native-apps, web-applications or we can use them for daily scripting on your favourite operating system.

Comparison categories

I would like to focus on a few concepts of programming languages that we are going to compare. Those categories are:

Data-type inferring
Generic inferring
Dynamic object types
Null pointer exceptions
Pattern matching
Modules import system
Runtime optimization
Not owned by mega-corporate

TLDR: goto final conclusion

1. Data-type inferring

F# is a strongly-typed language that implements an algorithm called Hindley–Milner. That algorithm analyzes your codebase and infers as much static types as possible.

If we want to write a function to sum two numbers in TypeScript, we have to define the data types for both arguments, and the TypeScript compiler will infer the Return type

// this is a function which takes 2 arguments: `a`, `b`, the function sums those numbers and returns a value
// here we have to define the data types of both arguments
let sum = (a: number, b: number) => a + b

On the other hand, F# analyses the source code and finds that the + operator can be called on two integers so it infers the data types of the arguments.

// this is a function which takes 2 arguments: `a`, `b`, the function sums those numbers and returns a value
let sum a b = a + b

F# is running on .net ecosystem so it makes a difference between float and int while TypeScript does not

As you can see, F# code looks like another scripting language without static types but because of the terrific F# compiler it's a type-safe and strongly typed snippet.

Thanks to the Hindley-Milner algorithm in the F# compiler, F# is the winner.
Unfortunatelly it looks like TypeScript has no plan to implement this kind of type inference.

🏆 F# won

2. Generic inferring

TypeScript use angle brackets <T> for generics. This is very similar to languages like C++, Java or C#. F# use just simple apostrophe 'T for it.

In TypeScript, we're able to infer simple return values and variable declarations, but if you want to have dynamic arguments like in this example:

const toDoubleTuple = <T>(anything: T): [T, T] => [anything, anything]

you have to define that the argument anything is of some generic type T and the function takes the type of anything and returns a tuple of [anything, anything]

As you may suggest, F# is so smart that it can even infer generic types of our function.

let toDoubleTuple anything = anything, anything

Again, F# analyzes the source code and finds that if a function takes anything of type 'a, it returns a tuple of anything, anything of type 'a * 'a. F# compiler infers that argument is of Generic type 'a. This code looks like a dynamic scripting language similar to Python but it has a powerful 100% type-safe runtime.

🏆 F# won

3. Dynamic object types

Now, let's compare how to create data-type and structural data objects. Let's start with F#.

type User = {
  id: string
  name: string
}

let kuba = {
  id = "my-id-123"
  name = "Kuba"
}

As you can see, F# has structurally based data object types. It means that F# compiler finds that there exists an object type with attributes id: string and name: string and it automatically infers its data type.

In TypeScript, if we create a data type, we have to assign that data type to a variable.

type User = {
  id: string
  name: string
}
// assign the data type to the variable
let kuba: User = {
  id: 'my-id-123',
  name: 'Kuba'
}

It's verbose so we have an alternative in TypeScript and we can infer the data type directly from the data by using the typeof keyword.

let kuba = {
  id: 'my-id-123',
  name: 'Kuba'
}
type User = typeof kuba

Thanks to the TypeScript approach, we may use more advanced generics like Omit<...>, Pick<...>, keyof and so on.

F# structural-based data object types are awesome but here the TypeScript has much more powerful, nicer and minimalist tools to define dynamic data object types.

🏆 TypeScript won

4. Null pointer exceptions

In JavaScript we have a few nullable values: null, undefined, 0, NaN, "". This makes it difficult to handle the JavaScript runtime properly. Thanks to TypeScript we can check the types more strictly.

let pipePrint = <T>(data: T | undefined | null) => {
  if (data === undefined || data === null || isNan(data)) {
    console.log('no value provided')
  } else {
    console.log(data)
  }
}

F# decided not to implement those nullable values and focused on forcing you to handle edge-cases strictly. So in the F# core there is a defined union type called Option
It's defined as:

type Option<'a> =       // use a generic definition
   | Some of 'a           // valid value
   | None                 // missing value

If we wrap some value in that Option type, we're able to check if the value exists or if the value is empty.

let pipePrint data = 
   match data with
     | Some x -> printf x
     | None -> printf "no value provided"

Thanks to that, F# compiler forces us to handle all non-valid potential null pointer exception errors, which is good. But in TypeScript, we have the same result if we type 100% of our codebase correctly. So in this category it is a draw and there is no winner.

🏆 no winner

5. Pattern matching

Pattern matching is a really powerful part of F# language design. There are many sources where you can find more information, like there or there.

TLDR:
Pattern matching in JavaScript/TypeScript is bad, not flexible, and bad again. So there the F# is the winner.

I put here one of many examples of the powerfulness of pattern-matching in F#.

let vectorLength vec =
    match vec with
    | [| var1 |] -> var1
    | [| var1; var2 |] -> sqrt (var1 * var1 + var2 * var2)
    | [| var1; var2; var3 |] -> sqrt (var1 * var1 + var2 * var2 + var3 * var3)
    | _ -> failwith (sprintf "vectorLength called with an unsupported array size of %d." (vec.Length))

🏆 F# won

Modules import system

F# has linear module system with namespaces and modules.

TypeScript has a few module systems like commonjs, ES6, and so on. Today we're gonna talk about ES6 imports.

To be honest, I don't like namespaces in programming languages like C#, Java, PHP, and so on. I prefer a module system where each file is its namespace and import & export are the only sign if the value is local, or if the value can be imported into a different module.

// file-a.fs
module FileA
let sum a b = a + b

// file-b.ts
module FileB
open FileA

ES6 modules enable us to have cyclic dependencies where names of files are part of our application architecture. In a language like C# and F# we have to create a file plus add a module or namespace declaration. I prefer a more minimalistic way of defining modules so I prefer the ES6 way.

// file-a.ts
export const sum = (a, b) => a + b


// file-b.ts
import { sum } from './file-a.ts'

🏆 TypeScript won

7. Runtime optimization

Both languages have really strong type inference systems. This means that the compiler will check the code and suggest (infer) the best static type to use. Thanks to that, you are able not to define static-type in the code on your own. It helps you to make a better development experience with less writing, but more readable, self-documented, and less error-prone code.

TypeScript is a highly dynamic language so if we compile our TypeScript code into the vanilla JavaScript, it removes static types and we're not able to use those metadata to optimize JavaScript runtime like memory allocation and CPU time.

On the other hand, thanks to the fact that TypeScript is a tool for a better developer experience, we're able to use expressions like as any, : any, @ts-expect-error, @ts-ignore and not to be too strict.

It means that both approaches have pros and cons, so there is no winner.

🏆 no winner

8. Not owned by mega-corporate

As you may know, F# is developed by Microsoft and it runs on the .net platform created by Microsoft as well. TypeScript is also created by Microsoft but the final output is pure vanilla JavaScript which is not owned by any large mega-corporate. Thanks to that, it gave us (as developers) the option not to be locked in one ecosystem of some mega-corporate and we are able to feel more free and independent.

Maybe this point could be stupid for you but I believe that it's better to write code in a language that is not so directly connected to anyone and there is more democracy.

🏆 TypeScript won

Final conclusion

So, Let's check the results of categories:

	F#	TS
1. Data-type inferring	🏆
2. Generic inferring	🏆
3. Dynamic object types		🏆
4. Null pointer exceptions	--	--
5. Pattern matching	🏆
6. Modules import system		🏆
7. Runtime optimization	--	--
8. Not owned by mega-corporate		🏆

So as you you can see, it's hard to decide which language I like more.
In conclusion, my dream language will be F# with Javascript ES6 module system and object data inferring via typeof.

Is there a solution?

So at the end of this article, it is worth mentioning that there is an awesome compiler fable.io that brings F# to the JavaScript ecosystem.

On the next screenshot you can see demo example where fable.io transpile one of our example from F# into the JavaScript.

If you enjoyed reading the article don’t forget to like it to make my day

Typed express with generated swagger docs

Jakub Švehla — Fri, 03 Sep 2021 12:13:54 +0000

Typed Express swagger-docs

TLDR:

I was missing some simple and minimalist libraries that would enhance Express API and solve some common problems with defining interfaces of my backend applications. I wanted to solve static type analysis, API documentation, and runtime validations from a single source of truth.

So I did a proof of concept for my dream library (now it's published in the alpha version).
The library enables you to just simply enhance your existing Express application endpoint handler and infer static types, add runtime HTTP validations, and generate documentation in the swagger format.
The library can do all of that from just one reusable single-source-of-truth (SSOT) in your codebase. It's just an Express handler HOF (higher order function aka js decorator for functions). Let's check the example below.

github repository

npm package

Package usage preview

Inferred typescript types from API definition

Generated Swagger API documentation from API definition

HTTP 400 bad request runtime validation error from API definition

Code definition

import { tSchemaInterfaceBuilder as T } from 'swagger-typed-express-docs'

app.get(
  '/',
    /**
   * adding single-source-of-truth metadata for the Express handler and a library to do the
   * - runtime validations checks
   * - compile-time checks
   * - generate swagger documentation
   */
  apiDoc({
    query: {
      name: T.string
      header: T.list(T.union(['a', 'b', 'c']))),
    },
    body: {
      header: T.list(T.union(['a', 'b', 'c']))),
      message: T.null_list,
      footer: T.string,
    },
    returns: T.null_object({
      data: T.null_object({
        nestedData: T.union(['a', 'b', 'c']),
      }),
    }),
  })((req, res) => {
    const body = req.body
    const query = req.query

    res.send({
      body,
      query,
    })
  })
)

Motivation

The problem with Express is that it does not solve HTTP REST-API runtime-validation, static types, and API documentation out of the box. So many programmers who use Express create their own "wrapper" around the Express and the project starts to be complex because there is not a standard Express backend approach. It's cool that you can bend Express in a way your business logic wants it to, but it makes the complexity of the whole project higher for other programmers. So I think that there should be a small standard of documenting API directly in your codebase.

I tried to look for another library in the current npm ecosystem that could satisfy our needs.

1. To define one SSOT (single source of truth) which would do
- 1. runtime schema validations
- 2. Typescript static time validations
- 3. Generating of documentation
2. Simplified minimalist API
3. Nice runtime-error messages
5. Support of REST-API

I tried hapi.js, nest.js, and other libraries but unfortunately, I found nothing, so I decided to create my solution which would fully satisfy our needs.

This article is intended to open a discussion if the API and the whole view on the problem is appropriate and to check if other people like the same approach as I do.

Thanks to simple APIs you can easily integrate Express endpoints one after another without breaking existing functionality with raw Express API.

Patterns used in the package API

SSOT / DRY

Many programmers try hard to keep the code DRY (don't repeat yourself). I think that a much more important pattern for clean code is the SSOT (single source of truth). It's very important to have a definition of your business state in only one place in your codebase. If you duplicate some parts of the state in more places you will end up with bugs in your programs because you
will forget to update all the relevant parts of the codebase.

Decorators vs Higher order functions

I decided to use a simple pure Javascript higher order function to decorate handlers instead of fancy pants class-based decorators API to simply keep the good old Express API of endpoints and not to be dependent on fancy experimental compilers options like decorators and so on.
If you want to know more about it, check this article.

Package future?

In the future, I would like to add few features which could add more flexibility to define a schema for Express handler endpoint

Cyclic dependencies

Cyclic dependencies of data types, similar to
graphql have already been defined.

Better support of creating custom data type

In the current library there is no official way how to create a custom data type with custom validators and custom type inference and you have to use one of the pre-defined types tBoolean tNumber tUnion tNonNullable tAny tObject tCustomScalar tString.

What do you think?

In my humble opinion, the npm ecosystem is missing some strong Typescript-supported solutions for handling that basic stuff like HTTP schema defining.

I would like to know your opinion about this kind of package API.

If you have any topics to discuss don't be shy to say them out loud in the comment section and open discussion.

If you enjoyed reading the article don’t forget to like it to tell me if it makes sense to continue.

Why reflect-metadata suc*s

Jakub Švehla — Mon, 31 May 2021 07:47:16 +0000

Modern Typescript oriented libraries start to use classes and decorators in their APIs.
Everything is awesome until libraries start to use reflect-metadata API which enforce you to define business logic in the static types which are magically reflected into your runtime code.

TLDR:

Don't vendor lock yourself with unsupported experimental syntax and
don't use reflect-metadata which forces you to pre-process your runtime code.

Use raw vanilla Javascript and infer Typescript data types directly from the Javascript definitions.

Good code



const userModel = model({
  id: nonNullable(stringType())
  name: nonNullable(stringType())
})

Bad code



@Model()
class userModel 
  /* decorators are nice syntax sugar ^^ */
  @Field()
  id: string /* problem is that business logic is coded in typescript type here */

  /* decorators are nice syntax sugar ^^ */
  @Field()
  name: string /* problem is that business logic is coded in typescript type here */
}

Check full working example of the good code in the Typescript playground

Or whole Github Repo

And... what is `reflect-metadata`?

Before we dig deeper to reflect-metadata we need to understand what are decorators Typescript decorators API.

Decorators

Decorators are syntax sugar which gives us the option to write quasi high-order-functions to enhance classes, methods, and properties.



class ExampleClass {
  @first() // decorators
  @second() // decorators
  method() {}
}

You may know a similar pattern from languages like C#, Java or Python.

If you compare Typescript decorators to the Python implementation,
you can find the difference that Typescript implementation does not work for basic functions or arrow functions.
At the top of it, the decorators are only a Typescript specific feature.
But we have to pay attention because similar functionality is already in the tc39 Javascript proposal at stage 2.

reflect-metadata

That was decorators, now we have to look for the reflect-metadata library.
Let's check the documentation.

Background

Decorators add the ability to augment a class and its members as the class is defined, through a declarative syntax.

Traceur attaches annotations to a static property on the class.

Languages like C# (.NET), and Java support attributes or annotations that add metadata to types, along with a reflective API for reading metadata.

If you don't fully understand who will use it in the real world you can check some libraries which use reflect-metadata to define the applications data models.

type-orm (~24K Github stars)
type-graphql (~6K Github stars)
nest.js (~37K Github Stars)
and so on...

If you know these libraries you know what I'm talking about.
Thanks to the reflect-metadata library you can "hack" into the Typescript compiler and get the static type metadata from compile-time into your Javascript runtime.

For example, you may have code like:



@ObjectType()
class Recipe {
  @Field()
  title: string;
}

The reflect-metadata library enables us to write decorators that will read metadata from the static type and this metadata may affect your Javascript runtime code.
You may imagine this metadata as an information that field title is string.

So that's pretty handy syntax sugar!

Yes...

But actually...

No... There is another side of the same coin.

Let's check on how to define an SQL table via the type-orm library using decorators and reflect-metadata.



@Entity()
export class User {
  @PrimaryGeneratedColumn()
  id: number;

  @Column()
  firstName: string;
}

As you may see, there is no Javascript runtime information about the data types of columns.
So that's magic because the basic Typescript compiler should transpile code into this:



@Entity()
export class User {
  @PrimaryGeneratedColumn()
  id;

  @Column()
  firstName;
}

The default Typescript compiler removes information about data types. Thanks to reflect-metadata and "emitDecoratorMetadata": true this code is still working
since it transfers information about static types into the runtime metadata descriptor which can be read in the Javascript runtime.

And where is the problem?

In my humble opinion the whole philosophy of influencing Javascript runtime via static types is bad and we should not use it in the Javascript ecosystem!

The reflect-metadata library has to influence the Typescript compiler and forces us to vendor lock our code into Typescript specific syntax so we're no longer able to use raw vanilla Javascript. The beauty of standard Typescript is that it just enhances the real Javascript codebase and enables us to have better integration, stability and documentation.

If some typings do not work correctly we can just use as any, @ts-expect-error or @ts-ignore, and everything is okay. We don't need to bend our application in the name of strict-type-safe-only faith. The strongest type-system advantage of Typescript over the others is that Typescript is just a tool for developers and it does not optimize the runtime.

If you define a variable in the C language, you know how many bits will be allocated in the memory thanks to the definition of a data-type.
At first glance, it could look like Typescript is missing this kind of optimization but on the other hand we should also realise that THIS is the game changer!
It enables us to just use a type system to help us document code and avoid runtime errors with the best developer experience.
If you combine this philosophy with Typescript type inferring you get the greatest dev-tool for avoiding runtime errors which is not affecting Javascript code.

If you're more interested in some fancy usage of Typescript type inference which solves real-world problems, you can check my other articles.

Reflect-metadata vs single source of truth (SSOT)?

If you use libraries like typed-graphql or type-orm you can find that reflect-metadata is only working for basic data types like: number, string, and boolean.
If you want to refer to another data type, you have to create a real Javascript pointer reference.

There are some real-world examples where you can see that the code is "duplicated" and you have to define real Javascript reference and static type reference.
It mean that you do not follow SSOT (Single source of truth) and DRY (Don't repeat yourself) at all.

type-orm example

(you should read comments in the code snippet)



@Entity()
export class PhotoMetadata {
  // here you have to define a reference into the real runtime Javascript pointer
  @OneToOne(type => Photo)
  @JoinColumn()
  // here you duplicate the pointer into Photo just to have proper static types
  photo: Photo;
}

type-graphql example

(you should read comments in the code snippet)



@InputType()
class NewRecipeInput {
  // here you have to define a reference into the real runtime Javascript pointer
  @Field(type => [String])
  @ArrayMaxSize(30)
  // here you duplicate the pointer into Photo just to have proper static types
  // so that means you can have an inconsistency between the static type and @Field(...) definition
  ingredients: string[];
}

Our target is to have SSOT which describes our data types and give us

Static type inferring
Infer cyclic pointer references
Option to have runtime Javascript validations
Type-safety
Good documentation
Enable us to use standard Javascript tooling
Enable us to generate the schema in the runtime

The solution

So we have explained why using reflect-metadata suc*s...so what should we use instead?
Thanks to Typescript generics we're able to write data types as a Javascript function composition or just simple hash-map/object.
Then we can Infer the data types. Thanks to that our code is pure Javascript, we're able to be more flexible and generate data types on the fly and not be fixed.

JSON Schema vs Class-based schema

In the previous examples we used class to define the schema, now we'll use a simple Javascript hashmap.
So let's define some basic ones.



const mySchema = {
  type: 'object' as const,
  properties: {
    key1: {
      type: 'number' as const,
      required: true as const,
    },
    key2: {
      type: 'string' as const,
      required: false as const,
    },
  },
  required: false as const,
}

The only Typescript-specific code there is the as const notation which defines that the data type should have been the same as the value.

We're able to write a data type for a schema like this:



export type SchemaArr = {
  type: 'array'
  required?: boolean
  items: Schema
}

export type SchemaObject = {
  type: 'object'
  required?: boolean
  properties: Record<string, Schema>
}

type SchemaBoolean = {
  type: 'boolean'
  required?: boolean
}
type SchemaString = {
  type: 'string'
  required?: boolean
}
type SchemaNumber = {
  type: 'number'
  required?: boolean
}

export type Schema = SchemaArr | SchemaObject | SchemaString | SchemaNumber | SchemaBoolean

Let's go deeper, Infer type from the Javascript schema!

Now we can create a generic which extracts the data type from the schema definition.



type NiceMerge<T, U, T0 = T & U, T1 = { [K in keyof T0]: T0[K] }> = T1

type MakeOptional<T, Required extends boolean> = Required extends true ? T : T | undefined 

export type InferSchemaType<T extends Schema> = T extends {
  type: 'object'
  properties: infer U
}
  ? // @ts-expect-error
  { [K in keyof U]: InferSchemaType<U[K]> }
  : T extends { type: 'array'; items: any }
  ? // @ts-expect-error
    MakeOptional<InferSchemaType<T['items']>[], T['required']>
  : T extends { type: 'boolean' }
  ? // @ts-expect-error
    MakeOptional<boolean, T['required']>
  : T extends { type: 'string' }
  ? // @ts-expect-error
    MakeOptional<string, T['required']>
  : T extends { type: 'number' }
  ? // @ts-expect-error
    MakeOptional<number, T['required']>
  : never

For simplicity I will not be describing how the InferSchemaType<T> generic was crafted. If you want to know more, just mention me below in the comment section.

This generic is kinda more complicated but if we look at the result we can see that the generics work perfectly.



type MySchemaType = InferSchemaType<typeof mySchema>

Or we can create builder util functions which build JSON with the nicer API.

You can check full source code here

Or in the Github Repo

This is phenomenal code to define a schema and infer a type from it.
It's very strong because it enables us to just write simple raw Javascript and 100% of static types are inferred via a few generics and functions.

At the end...
Thanks to omitting experimental Typescript API and returning into good old Javascript we don't vendor-lock our code into the Typescript compiler.

Validators

Even if we want to have runtime-validations, it's super easy to write a runtime validator on top of this schema definition.

If you're more interested in how to write validation from schema you can check the source code on my Github
https://github.com/Svehla/reflect-metadata-SCKS/blob/master/index.ts

Use High-order-functions vs Decorators API

But what if you just like decorators and you want to enhance some functions?

Decorators are just syntax-sugar. We can program the same in raw Javascript with a few TS generics.

Decoration API



class ExampleClass {
  @first() // decorator
  @second() // decorator
  method() {
    console.log('hi')
  }
}

HOF (high-order-function) API

Raw Javascript



// these two examples are not the same because 
// 1. the second one will  instance the method function code every time that class is instanced
// 2. there is different `this` binding
// but we'll ignore that small difference and we'll focus on different stuff...
const fn1 = first()(second()((self) => {
  console.log('hi')
})))

with usage of Ramda.js library



import * as R from 'ramda'

const fn1 = R.pipe(
  second(),
  first()
)(self => {
  console.log('hi')
})

If you want to see more about how to add proper types for HOC or the Pipe function just tell me down in the comment section.

Who should care about this article the most?

The problem is not with the regular programmers who just install npm libraries.
The problem is the authors of libraries who think that this new reflect-metadata API with experimental decorators will save the world, but at the opposite side it just vendor locks your codebase into 1 edge-case technology.

Is there some good library too?

Haha! good question, of course there is.

I picked two libraries which uses the same philosophy as we described in this article.

1. Typed-env-parser

Typed env parser - npm.
Typed env parser - github.

If you look for the API:

You can find that the definition of users does not include Typescript and the API of the function is pure Javascript.
Thanks to the type inference we get all the features of a strongly typed system in vanilla js implementation.

2. Yup

Yup - npm

Yup enable us to define JS schema and infer its data type from raw Javascript schema.

Well That's all...

I hope that you find time & energy to read whole article with a clear and open mind.
Try to think about the syntax which you may use in your codebase on the daily basis and be sceptical about new fancy stuff, which enforces you to do extra compilation to make the code work...

If you enjoyed reading the article don’t forget to like it to tell me if it makes sense to continue.

React typed state management under 10 lines of code

Jakub Švehla — Wed, 26 May 2021 15:25:14 +0000

Goal

The goal of this tutorial is to write "strong" state management with 100% type inference from the javascript code.

TLDR:

Final example of the state management is available on github

or you can find a fully working example at the end of this article.

Historical background

React introduced hooks about 2 years ago.
It changed the whole ecosystem and it shows up that we can write an application without using external
state management libraries like redux or mobx and we'll still have nice minimalist code.

We were able to do the same even before the hooks were introduced,
but the problem was that the renderProps/HOC/Classes API wasn't that nice and elegant as hooks are.

If you know that you want to use Redux and you're struggling with Typescript type inference, you can check this article

Tooling of vanilla React is still pretty strong but if you have an application
with tons of lines of code that's too complex for ordinary humans, you can
start to think about some third-party state management libraries.

Custom state management Wrapper

React context is a nice option on how to split parts of your global application logic into different
files and define a new React.createContext for each module.
Then you just import the context instance and use it in the component instance by useContext hook.
A great feature of this pattern is that you don't re-render components that are not directly connected to the state that is changed.

In pure vanilla React you can write your state management via context like this.

import React, { useState, useContext } from 'react'
const MyContext = React.createContext(null)

const LogicStateContextProvider = (props) => {
  const [logicState, setLogicState] = useState(null)

  return (
    <MyContextontext.Provider value={{ logicState, setLogicState }}>
      {...props}
    </MyContextontext.Provider>
  )
}

const Child = () => {
  const logic = useContext(MyContext)
  return <div />
}

const App = () => (
  <LogicStateContextProvider>
    <Child />
  </LogicStateContextProvider>
)

Everything looks nice until you start to add Typescript static types.
Then you realize that you have to define a new data type for each React.createContext definition.


/* redundant unwanted line of static type */
type DefinedInterfaceForMyCContext = {
  /* redundant unwanted line of static type */
  logicState: null | string
  /* redundant unwanted line of static type */
  setLogicState: React.Dispatch<React.SetStateAction<boolean>>
  /* redundant unwanted line of static type */
}

const MyContext = React.createContext<BoringToTypesTheseCha>(
  null as any /* ts hack to omit default values */
)

const LogicStateContextProvider = (props) => {
  const [logicState, setLogicState] = useState(null as null | string)

  return (
    <MyContext.Provider value={{ logicState, setLogicState }}>
      {...props}
    </MyContext.Provider>
  )
}

/* ... */

As you can see, each React.createContext takes a few extra lines for defining Typescript static types
which can be easily inferred directly from the raw Javascript implementation.

Above all, you can see that the whole problem with inferring comes from the JSX. It's not impossible to infer data types from it!

So we have to extract raw logic directly from the Component and put it into a custom hook named useLogicState.

const useLogicState = () => {
  const [logicState, setLogicState] = useState(null as null | string)

  return {
    logicState,
    setLogicState
  }
}

const MyContext = React.createContext<
  /* some Typescript generic magic */
  ReturnType<typeof useLogicState>
>(
  null as any /* ts hack to bypass default values */
)

const LogicStateContextProvider = (props) => {
  const value = useLogicState()

  return (
    <MyContext.Provider value={value}>
      {...props}
    </MyContext.Provider>
  )
}

const Child = () => {
  const logic = useContext(MyContext)
  return <div />
}

const App = () => (
  <LogicStateContextProvider>
    <Child />
  </LogicStateContextProvider>
)

As you can see, decoupling logic into a custom hook enable us to infer the data type by ReturnType<typeof customHook>.

If you don't fully understand this line of TS code ReturnType<typeof useLogicState> you can check my other Typescript tutorials.

I also don't like the fact that there is a lot of redundant characters which you have to have in the code
every time you want to create new React context and it's own JSX Provider Component which we use to wrap our <App />.

So I have decided to extract and wrap all dirty code in its own function.
Thanks to that we can also move that magic Typescript generic into this function and we'll be able to infer the whole state management.

type Props = { 
  children: React.ReactNode 
}

export const genericHookContextBuilder = <T, P>(hook: () => T) => {
  const Context = React.createContext<T>(undefined as never)

  return {
    Context,
    ContextProvider: (props: Props & P) => {
      const value = hook()

      return <Context.Provider value={value}>{props.children}</Context.Provider>
    },
  }
}

So we can wrap all this magic which is hard to read into a ten-line function.

Now the genericHookContextBuilder function takes our state hook as an argument and generates Component which will work
as an App Wrapper and Context which can be imported into useContext.

we're ready to use use it in the next example.

Full example

import React, { useState, useContext } from 'react';


type Props = {
  children: React.ReactNode
}

export const genericHookContextBuilder = <T, P>(hook: () => T) => {
  const Context = React.createContext<T>(undefined as never)

  return {
    Context,
    ContextProvider: (props: Props & P) => {
      const value = hook()

      return <Context.Provider value={value}>{props.children}</Context.Provider>
    },
  }
}

const useLogicState = () => {
  const [logicState, setLogicState] = useState(null as null | string)

  return {
    logicState,
    setLogicState
  }
}

export const {
  ContextProvider: LogicStateContextProvider,
  Context: LogicStateContext,
} = genericHookContextBuilder(useLogicState)

const Child = () => {
  const logic = useContext(LogicStateContext)
  return <div />
}

const App = () => (
  <LogicStateContextProvider>
    <Child />
  </LogicStateContextProvider>
)

As you can see, we have written a small wrapper around native React context default verbose API.
The wrapper enhanced it with out-of-the-box Typescript type inference, which enabled us not to duplicate code and to save a lot of extra lines.

I hope that you enjoyed this article the same as me and learned something new. If yes don't forget to like this article

World-first Static time RegEx engine with O(0) time complexity

Jakub Švehla — Mon, 15 Feb 2021 15:45:49 +0000

What the heck is that?

RegEx engine written with static types?!
Code which evaluates RegEx "templates" in compile time so you know the result before you run your app?!
RegEx engine which works with O(0) run-time complexity?!
Minified 0-bite (GZip) length output?!
Fully bugged and not ready for production?!

I'm not kidding!!! This is not just a dream!

This is the first world RegEx engine written in pure Typescript types.

Check the working examples!

Github Repo - ts-generics-RegEx-engine

you can play with the source code here

Disclaimer

The code is not ready to use in production environment.
Because of the stack limits of Typescript, some regExs stop working because they are too long and trigger recursion stack overflow known as Type instantiation is excessively deep and possibly infinite.
RegEx backtracking is not implemented yet.
The parser supports only a small subset of PCRE standard. Specifically .?*+()\\ symbols.

Motivation + usage

Thanks to new features of Typescript 4.1.x we are able to parse a string into a Tuple of tokens and much more! So I decided to write my own custom RegEx engine just by using Typescript static types to demonstrate how powerful the type system of Typescripts is.

How does the RegEx engine work under the hood?

As you may know, programming languages compilers + interpreters. You may know that they are pretty complex and includes Lexers, Parsers, Interpreters, and so on.

On the other side, this small engine is quite simple, so there are just 3 small modules:

1. Tokenizer
2. Parser
3. Interpreter

1. Tokenizer

A small generic type TokenizeString<T> just parses RegEx template to tokens which are used as the input for 2. Parser to build RegEx Abstract-Syntax-Tree (AST).

Examples:

type T0 = TokenizeString<'\\(+(ab)+'>

type T1 = TokenizeString<'\\(+(a(xy)+(xx)b)+'>

2. Parser

type ParseRegExTokens<T> = ... takes the tokenized template and does the syntax analysis which produces an Abstract-Syntax-Tree (AST) Model of the RegEx template.

Examples:

type T3 = ParsedRegEx<TokenizeString<'\\(+(a(xy)+(xx)b)+'>>

As you can see, the parser supports nesting of structures (like brackets in brackets in brackets etc...)

AST for '\\(+(a(xy)+(xx)b)+' template will look like this:

[{
    type: 'element';
    value: "(";
    quantifier: 'exactlyOne';
}, {
    type: 'element';
    value: "(";
    quantifier: "zeroOrMore";
}, {
    type: 'groupElement';
    states: [{
        type: 'element';
        value: "a";
        quantifier: 'exactlyOne';
    }, {
        type: 'groupElement';
        states: [{
            type: 'element';
            value: "x";
            quantifier: 'exactlyOne';
        }, {
            type: 'element';
            value: "y";
            quantifier: 'exactlyOne';
        }];
        quantifier: 'exactlyOne';
    }, {
        ...; // and so on
    }, {
        ...; // and so on
    }, {
        ...; // and so on
    }];
    quantifier: 'exactlyOne';
}]

3. RegEx Interpreter

The last step is to create a proper "interpreter" type Test<RegExp, TestString> = ... which takes a template and a test string by applying rules from the RegEx AST.

Examples:

And that's it! 🎉 🎉

If you don't believe, you can check the full source code in this GitHub repo: https://raw.githubusercontent.com/Svehla/ts-generics-RegEx-engine

Wait... And what about the real Javascript output? Let's check it out!

Haha! A few hundreds line of static types and runtime output is empty with O(0) time complexity! That's the magic of Typescript 🦄

And what's next?

If you're interested in another advanced usage of the Typescript type system, you can check these step-by-step articles/tutorials on how to create some advanced Typescript generics.

How to UPPER_CASE to camelCase in raw Typescript generics

Jakub Švehla — Fri, 29 Jan 2021 09:48:17 +0000

TLDR:

Today's challenge is to retype an UPPER_CASE static string into camelCase and apply this transformation recursively to the object keys.

Preview

As you can see, we transformed static type text written in UPPER_CASE format into camelCase. Then we applied the transformation recursively to all the object keys.

You can play with full source code here

Typescript 4.2 is already in beta version, so we should be prepared for new incoming features to fully use the power it offers. You can find all the new Typescript 4.2 features there: https://devblogs.microsoft.com/typescript/announcing-typescript-4-2-beta/

Let's deep dive into code

To change the case from UPPER_CASE to camel Case, we have to use the parser to convert uppercase letters to lowercase ones and to remove unwanted _.

Letters mapper

First of all, we create the Lower/Upper Mapper type which describes dependencies between lowercase and uppercase letters.



type LowerToUpperToLowerCaseMapper = {
  a: 'A'
  b: 'B'
  c: 'C'
  d: 'D'
  e: 'E'
  f: 'F'
  g: 'G'
  h: 'H'
  i: 'I'
  j: 'J'
  k: 'K'
  l: 'L'
  m: 'M'
  // ... and so on 
}

type UpperToLowerCaseMapper = {
  A: 'a'
  B: 'b'
  C: 'c'
  // ... and so on 
}

Parse strings Utils

We have to write a small parser that will read UPPER_CASE format and try to parse it to the new structure which will be transformed into camelCase. So let's start with a text parser util function.

HeadLetter

This generic infers the first letter and just returns it.



type HeadLetter<T> = T extends `${infer FirstLetter}${infer _Rest}` ? FirstLetter : never

TailLetters

This generic infers all the letters except the first one and returns them.



type TailLetters<T> = T extends `${infer _FirstLetter}${infer Rest}` ? Rest : never

LetterToUpper

This generic calls the proper LowerCase Mapper structure to convert one char.



type LetterToUpper<T> = T extends `${infer FirstLetter}${infer _Rest}`
  ? FirstLetter extends keyof LowerToUpperToLowerCaseMapper
    ? LowerToUpperToLowerCaseMapper[FirstLetter]
    : FirstLetter
  : T

LetterToLower



type LetterToLower<T> = T extends `${infer FirstLetter}${infer _Rest}`
  ? FirstLetter extends keyof UpperToLowerCaseMapper
    ? UpperToLowerCaseMapper[FirstLetter]
    : FirstLetter
  : T

ToLowerCase

Now we're albe to recursively call HeadLetter, Tail and LetterToLower to iterate through the whole string and apply lowecase to them.




type ToLowerCase<T> = T extends ''
  ? T
  : `${LetterToLower<HeadLetter<T>>}${ToLowerCase<TailLetters<T>>}`

ToSentenceCase

This generic transforms the first letter to uppercase and the rest of the letters to lowercase.



type ToSentenceCase<T> = `${LetterToUpper<HeadLetter<T>>}${ToLowerCase<TailLetters<T>>}`

We're done with all our utils Generics, so we can jump into the final type implementation.

UpperCaseToPascalCase

We're almost there. Now we can write the generic which will transform CAMEL_CASE into PascalCase.



type ToPascalCase<T> = T extends ``
  ? T
  : T extends `${infer FirstWord}_${infer RestLetters}`
  ? `${ToSentenceCase<FirstWord>}${ToPascalCase<RestLetters>}`
  : ToSentenceCase<T>
```

As you can see, we recursively split words by `_` delimiter. Each word converts to `Sentencecase` and joins them together.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/1rj0ypv0h3n6fa4c40aj.png)

### UpperCaseToCamelCase
The last step is to use `PascalCase` but to keep the first letter of the first word lowercase.

We use previously created generics and just combine them together.

```typescript
export type UpperCaseToCamelCase<T> = `${ToLowerCase<HeadLetter<T>>}${TailLetters<ToPascalCase<T>>}`
```

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/z8896snhd26k8vttz4dr.png)


Pretty amazing and kinda simple code, right? 

## Apply case transformation to object keys

Now we want to build a static type that applies recursively `UpperCaseToCamelCase` generic to Object nested keys.

Before we start, let's define three helper generics.


#### GetObjValues
```typescript
type GetObjValues<T> = T extends Record<any, infer V> ? V : never
```

This simple generic helps us to extract data outside of a `Record<any, T>` wrapper.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/zmtkvxeken62a9fmqwl6.png)


#### Cast

This generic helps us to bypass the Typescript compiler to pass invalid types. We will use Cast<X, Y> to "shrink" a union type to the other type which is defined as the second parameter.


```typescript
type Cast<T, U> = T extends U ? T : any
```

```typescript
type T4 = string | number
type T5 = Cast<T4, string>
```

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/cxe1if6azoxac9xllypt.png)

#### SwitchKeyValue

We use our previously defined generic `GetObjValues<T>` to switch the to the value. 

The goal of this generic is to transform the string value into the key and vice-versa, like in the preview.

```typescript
type Foo = SwitchKeyValue<{ a: 'key-a', b: 'key-b' }>
```

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/jo3p5452hft697turzh1.png)


```typescript
type GetObjValues<T> = T extends Record<any, infer V> ? V : never

export type SwitchKeyValue<
  T,
  // step 1
  T1 extends Record<string, any> = {
    [K in keyof T]: { key: K; value: T[K] }
  },
  // step 2
  T2 = {
    [K in GetObjValues<T1>['value']]: Extract<GetObjValues<T1>, { value: K }>['key']
  }
> = T2
```


The whole procedure takes, two steps so I decided to keep the code less nested and to save partial values into variables. Sub results variables are saved due to generic parameters. Thanks to that Typescript feature I can "save" the results of transformations into "variables" `T1` and `T2`. This is a pretty useful pattern of writting static types with less nesting.

Everything works fine so let's dive into recursive nested keys transformation.

### TransformKeysToCamelCase

Now we will combine the generics from the whole article into one single piece of art.


```typescript

type TransformKeysToCamelCase<
  T extends Record<string, any>,
  T0 = { [K in keyof T]: UpperCaseToCamelCase<K> },
  T1 = SwitchKeyValue<T0>,
  T2 = {
    [K in keyof T1]:T[Cast<T1[K], string>]
  }
> = T2
```

```typescript
type NestedKeyRevert = TransformKeysToCamelCase<{
  FOO_BAR: string
  ANOTHER_FOO_BAR: true | number,
}>
```

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/cw1tvlcelhkxmf765osl.png)


As you can see, the generic has 3 steps which are saved into `T0`, `T1` and `T2` variables. 

#### The First step

The first step creates an Object type where keys are UPPER_CASE and values are just keys transformed into camelCase   

```typescript
T0 = { [K in keyof T]: UpperCaseToCamelCase<K> },
```

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/2k8simblt3582u22moly.png)

#### The second step
The second step just applies the previously created generic and switch keys to values

```typescript
T1 = SwitchKeyValue<T0>,
```

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/rxn79p8b4e0z3lsvvsre.png)


#### The third step

The third step connects `T1` with the data type from `T`.

```typescript
T2 = { [K in keyof T1]: T[Cast<T1[K], string>] }
```

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/cw1tvlcelhkxmf765osl.png)

### Add nested deep recursion

To provide this, we will create a generic which will check if the value is of type Object and will call recursion.

```typescript
type CallRecursiveTransformIfObj<T> = T extends Record<any, any> ? TransformKeysToCamelCase<T> : T

```

And updates the third step of TransformKeysToCamelCase generic.

```typescript

type TransformKeysToCamelCase<
  T extends Record<string, any>,
  T0 = { [K in keyof T]: UpperCaseToCamelCase<K> },
  T1 = SwitchKeyValue<T0>,
  T2 = { [K in keyof T1]: CallRecursiveTransformIfObj<T[Cast<T1[K], string>]> }
> = T2
```



And voilà! 🎉🎉🎉


If we test the nested data structure as a generic parameter

```typescript
type NestedKeyRevert = TransformKeysToCamelCase<{
  FOO_BAR: string
  ANOTHER_FOO_BAR: true | number,
  NESTED_KEY: {
    NEST_FOO: string
    NEST_BAR: boolean
  },
}>
```

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/de4h6qg9obi1fzm7zwd1.png)


Everything works well.

Congratulations that you have read this article until the end. We successfully added a nested key case transformation which is a pretty advanced task in raw typescript.


[You can play with the full source code here](https://www.typescriptlang.org/play?target=1#code/C4TwDgpgBAMg9gdwgJwCpwKpkmu8nIDCAhgM4QCyx2KUAvFAN4CwAUFFMQFxQDkAgrzYcARj14AhIeygBjcYWkcAJuIAiSqBHEBRTQDNxAMU0BzcQHFNAC3EAJTQEtxASU0ArcQClNAa3EA0poANuIwmgC24hSaAHbiAHKacOIA8ppg4gAKmgCO4gCKmsjiAEqapOIAyprA4qiaAK7iGJoAbuIAapoI4gDqmgAe4gAamiDiAJqaAF7iAFrSAL5sbKCQUFg46PgoJORUNMj0TMJQ-OLEmhLiIpqE4rKaauLKmjriEJpG4vqaFuJTJo7OJrJoXOJHJovOJ3JoAuJfJoYOJgpoKOIIpoEuJYppUuI4JosuIwJoCuJcppSuJkJoquJSJpUOJgJoMOJGppOuI2po+uIEJoRuJBppJuIQJp5uIZstVqw1uBoHYIMRlDAIMBgCgADyoAB8J1QWkGOtiylIUAABgASRiOWL6WhGRzIUjATXalBLe2O53HAD6pQgHqW1qgAH4oK73Z6tTrjjxYhA2iglRtUMRHMEvYnSPqjQwTRAzRALVa7Q6nbRA7GPXmfX6a8cQ2GI9G28AoMnU+nFax1tBG7gtnrDcbTebLTbmwGY26Gwmm9X58HQ8Bw2do-X497jqXp1bfBAQHB9LBECh0GPcLsiGRKNQcGcONH7zejjsrw+Ds+UAA2ruI4ALqvj2C5xiOZw8KgCpDrAy53j+haToe5YzlW-ououe6Jr6q61l2W4yDuuEjlOGHHqe56bF+eA-vsT5HOB0a3t+BBMYcOBAeRSFgTIHA8MBSEwVAcEDghHF7I+qHFpRFZ8Jo0YSUJs6MCO0nILqqrqiOhYGgRWlMfq2a5khBaGoZ1oKgA9LZkEelAwRIVAjhWo0RxQMgG5uVawQ-hm0DoFU5bmrIEAmRODBVppmBHDpaoakhBlGQxnGyVmOYjpZBrWfByriXAWRkLIxDBFFRbiQpmE2aR4liSWZaKVhLaOcAfRwMgyhLIGc60F2OUkW+6khWF5YRSZu6dd1hn2ugJWkGVFWyYNFn5TIsFwKFsThZFmUGgqpZgF13YIbeTHoCQEQQCt5ByaN6UyfdunJfuqXzWZOX6sVpXlZVG1sPZnDYMEIBQKQsTECeciPm5u1wFAcAiO4ECyMApBBVA+zAPqAA0mxVU1R6bFG1U8BgWMWFqqQo505WNKGD3E1RUAhrIXXKLqxCxCABPYccnRGtGnQQSmabIAVGwkMEwTs407qOGmqDIDzpD6F1EQuPotPuMzNVWuznPc7zBM8yAwviarsTq5rASnqQV3EDdd0QKhsFHYMJ3IGdhVVAgjjALI1j2yA9PBIzupnKgePRwAjAbbNo8bHrII6phm7zVUsIJUAAQE8NQCeZ4XqgIE8IwRenjwAQANxQG0DPaOJ+cgVAKwyEsscyKgABMJw5xwHD54X1PALr4eM5ZccGgBvCNxHXwgeXUA6Gaqvo7qY8T0308GgTlcL4zNft7PvDF7wAkcB3RO91LwXW7byARKHjtwNdt0mdHidG91uqp+nTOFtu4cFQAABgHnnAujoq4l3EivC6j4nYuxMgEI0Xd44nH9oHYOodJ5u3AfvaO-cGCVxHjA4utFUBxxXjLOWaMFakCVhAFWasNbP21rrfUAEcb6jjq3AmADYimANCBdBbBb4KixgkDcEBlChxDBLbsxZH7sJfg7ZBn9ZKDxjKkVIgYJD8BpBDYAadhFnH4AkVIqA7A6FKHWPRBijE8FMYzKAAAfKAsRGgRBECgEBUAEg6CqKgHQahAwBB0BKU4ucgkhIcQSExZjTDgTiagJxxiRBwDgC5HmZwMGsCWIdVgQA)

Don't forget to 🫀 if you like this article.

Type inferred react-redux under 20 lines

Jakub Švehla — Mon, 09 Nov 2020 17:26:55 +0000

TLDR:

We’re gonna implement a static-type layer on top of the Redux App. Our goal is to write a minimalistic but 100% type-safe code. To do it well, we‘re gonna write code that will be more about type inferring and creating the data connection than about writing types.

Final source-code usage previews:

Inferred redux state from reducers

const reducers = {
  users: usersReducer,
  helpers: combineReducers({
    counter: counterReducer,
  }),
};

export type GlobalState = GetStateFromReducers<typeof reducers>

Inferred union of all possible redux actions

const reducers = {
  users: usersReducer,
  helpers: combineReducers({
    counter: counterReducer,
  }),
};

export type AllReduxActions = GetAllReduxActions<typeof reducers>

Inferred returned value of selectors

const getCounterValue = (state: GlobalState) => state.helpers.counter.value

const counterValue = useSelector(getCounterValue)

Inferred nested action payload by action type inside of reducer switch-case

You can find the full redux-typescript app in my GitHub repository:
https://github.com/Svehla/typed-react-redux

Prerequisites

If you're not 100% sure about your Typescript skills you can check these beginner sources:

Basic static types inferring:

Let's start

You could ask yourself. “**We can just read the official documentation and that’s it, right?” **Unfortunately, the official Redux Typescript guide is not suitable for our inferring mindset.

In my humble opinion, the official React-Redux guide contains a lot of programming bottlenecks like repeatable code and a lot of abstraction and complexity. I don’t recommend to be inspired by that, you should just prefer to continue with reading this Typescript article.

Redux is a simple tool that is used to handle state management in modern web apps. Unfortunately Redux has some patterns which add a lot of unnecessary abstraction for a simple state management library. You have to create tons of functions that communicate over one black-box (Redux) which takes them all and makes some state changes and updates. Another problem with Redux is that there are no statically-analyzed source code connections, so you as a programmer don’t see dependencies and relationships between your Javascripts objects and functions. It’s like throwing functions into the air and check if it all works correctly. Of course Redux has a lot of useful features so it’s not bad at all. For example, Redux dev-tools are nice and you can simply use them as there are. Redux is also useful for large teams. Especially in a place where a lot of people contribute to the same repository at the same time.

Let’s have a look at Redux architecture. There are some middlewares, reducers, selectors, actions, thunks and at top of it, there is a Redux the black-box library which merges all pieces together and creates a global store.

In the diagram below we have the basic Redux data flow.

Data flow is simple and straightforward, which is awesome right?

So let’s have a look at another diagram, which shows the basics of Javascript source code relations with the usage of Redux.

Redux forces you to write a lot of small functions that are all merged together in the heart of the Redux library, so it’s hard to do static-analyses and find relations between these pieces of abstractions

Let’s add static-types

So our target is to create some Typescript glue that connects all these abstract parts (sectors, actions creators, reducers, etc…) together and makes Redux statically-analyzable, readable and type-safe.

Code snippets from this article are from this react-typescript repo:
https://github.com/Svehla/redux-ts-preview

Action creators

Action creators are functions that return a new object that is dispatched into Redux.

const MULTIPLY = 'MULTIPLY' as const 
const DIVIDE = 'DIVIDE' as const
const multiply = (multiplyBy: number) => ({
  type: MULTIPLY,
  multiplyBy,
})
const divide = (divideBy: number) => ({
  type: DIVIDE,
  divideBy,
})

We’re gonna add a few Typescript types which help us to create data-types for action creators.

We have to use as const for setting up action names like the enum value for future pattern-matching.
We have to add types for function arguments
We create ActionsType enum which enables us to logically connect actions to a reducer.

// global uniq names
// use `as const` for fixing value of type
const MULTIPLY = 'MULTIPLY' as const
const DIVIDE = 'DIVIDE' as const
const multiply = (multiplyBy: number) => ({
  type: MULTIPLY,
  multiplyBy,
})
const divide = (divideBy: number) => ({
  type: DIVIDE,
  divideBy,
})
// create options type for all action creators
// for one reducer. all data types are inferred
// from javascript so you don't have to
// synchronize types with implementations
type ActionType =
  | ReturnType<typeof multiply>
  | ReturnType<typeof divide>

Reducer State

Each reducer has a state. Let’s define the basic one.

const defaultState = {
  value: 10
}

We use Typescript as a glue for our Javascript code, we don’t want to reimplement the shape of the defaultState into an Interface by hand, because we trust our Javascript implementation. We will infer the type directly from the Javascript object.

const defaultState = {
  value: 10
}
type State = typeof defaultState

As you can see it’s no big deal to infer a static type for the whole reducer state by using a single typeof keyword. There is a bottleneck if a default value does not describe the whole data type and Typescript can’t infer it correctly. For example an empty array. If you write an empty array you have no idea what data types will be inside of the array. For this kind of case, we will help the typescript-compiler by using the as keyword for specifying the type correctly as in the example below.

const defaultState = {
  users: [] as User[],
  admins: [] as User[],
}
type State = typeof defaultState

Reducer

Reducer is a pure function that takes state and action and returns a new updated state. Basic Javascript implementation is just function with oneswitch caseas in the example.

function counter(state = defaultState, action) {
  switch (action.type) {
    case MULTIPLY:
      return { ...state, value: state.value * action.multiplyBy }
    case DIVIDE:
      return { ...state, value: state.value / action.divideBy }
    default:
      return state
  }
}

Adding Typescript to the reducer is simple. We will just connect reducers arguments with already created Typescript inferred State type and an ActionType enum with all reducers actions.

You can see that switch-case pattern matching started to magically infer a data type from the return value of the action creator function.

Combine reducers

combineReducers is a function that connects all the reducers into one giant nested object that is used as a global state which is a source of truth for the whole application. We know that a reducer returns an app sub-state which we inferred via typeof from the default State. So we are able to take the return value of all reducers and combine them to get the state of the whole App. For example:

const reducers = {
  users: usersReducer,
  helpers: combineReducers({
    counter: counterReducer,
  }),
};

We will infer the App state by combing all reducers and apply the GetStateFromReducers generic which merges all reducers sub-states. combineReducers can be nest so our type inferring should works recursively. Generic GetStateFromReducers is a small util type that recursively infer returns values of all nested reducers and combines them into the global type.

export type GetStateFromReducers<T> =
  T extends (...args: any[]) => infer Ret
  ? Ret
  : T extends Record<any, any>
  ? {
      [K in keyof T]: GetStateFromReducers<T[K]>
    }
  : T

Now we just apply our generic to the reducers object and infer the App state.

const reducers = {
  users: usersReducer,
  helpers: combineReducers({
    counter: counterReducer,
  }),
};

export type GlobalState = GetStateFromReducers<typeof reducers>

If you add a new reducer into the Javascript implementation, Typescript automatically infers a new global state. So there are no duplicates of writing interfaces and implementation because everything is automatically inferred.

Selectors

Redux selector is a small function that takes global Redux state and picks some sub-state from it.

const getCounterValue = (state: GlobalState) => state.helpers.counter.value

Now we connect the created selector to the React component by the useSelector hook.

const counterValue = useSelector(getCounterValue)

Typescript connections preview

When you inferred the whole Redux state from the real Javascript implementation you get extra Typescript code connections between selectors and reducers. You can check it in your favorite IDE (I use VSCode) just by clicking something like a command/CMD + mouse click to data-type and IDE should jump to the code definition. If you try to do it the newly created example, an IDE will be redirected directly to the core implementation.

export const UIApp = () => {
  const dispatch = useDispatch()
  return (
    <div>
      <button onClick={() => { dispatch(divide(4))}}>divide by 4</button>
    </div>
  )
}

It means that type inferring is much more valuable than just type interfaces written by hand! And you get it because you did not create an extra layer of a data shape abstraction and you just infer connections between your functions and objects.

Dispatch action directly from the React Component

You already created all redux actions so we’re gonna connect them with React Component. In pure React Javascript, code will be similar to this one.

We use the useDispatch hook to get dispatch function. dispatch takes action object which is created by our action creators (later in this chapter you will find out that you can pass also redux-thunk function). We want to create a union type for all possible Redux actions. We already combined all reducers together by combineReducer. So we will just take a second argument (action) of all reducers and get a union type for all of them.

We define another generic which recursively infer the second argument of all nested functions in objects.

export type GetAllReduxActions<T> = T extends (state: any, actions: infer Actions, ...args: any[]) => any
  // omit empty objects like `{}`
  ? keyof Actions extends []
    ? never
    : Actions
  : T extends Record<string, infer Values>
  ? GetAllReduxActions<Values>
  : never

Now we pass typeof reducers into generic and we get union of all possible actions!

const reducers = {
  users: usersReducer,
  helpers: combineReducers({
    counter: counterReducer,
  }),
};

export type AllReduxActions = GetAllReduxActions<typeof reducers>

The last step is to re-declare a global data type for react-redux library and connect created AllReduxActions type to the useDispatch hook.

To do that we have to create global.d.ts a file where we replace libraries definitions with our custom ones. In this file, we redeclare the scope of react-redux library and change the Typescript type of useDispatch. We redeclare react-redux types by using of declare module xxx { You can read more about adding types to different modules there:
https://www.typescriptlang.org/docs/handbook/modules.html#ambient-modules

import { AllReduxActions } from './App'
import { ThunkReturnType } from './reduxHelperTypes'

declare module 'react-redux' {
  type UnspecificReduxThunkAction = (...arg: any[]) => any
  export function useDispatch(): (arg: AllReduxActions | UnspecificReduxThunkAction) => Promise<any>
}

In this global.d.ts we already added support for redux-thunk by ThunkReturnType generic which will be described in the next part of this article.

We already defined all necessary pieces and we’re able to use useDispatch with a correctly typed all actions argument.

*arg arguments contain all users/ and count/ actions but this union type is too large to be in one screenshot

Async actions with `redux-thunk`

The last missing thing from our Redux example is async action dispatching. For this article, we choose to use redux-thunk library because it’s a simple package that is heavily used in the whole Redux ecosystem.

Redux-thunk enables us to write a function that takes custom parameters and returns a new function with pointers to dispatch and getState functions that enable you to create async Redux work-flow. If you don’t know redux-thunk look at the documentation. https://github.com/reduxjs/redux-thunk

A basic Javascript redux-thunk async function example.

const delay = (timeout) => new Promise(resolve => setTimeout(resolve, timeout))

export const asyncValueChange = (timeout) =>
  async (dispatch, _getState) => {
    await delay(timeout)
    dispatch(multiply(2))
    await delay(timeout)
    await delay(timeout)
    dispatch(multiply(5))
    await delay(timeout)
    dispatch(divide(7))
  };

It would be a lot of work to write types for each function argument. Because of that, we created another util generic calledThunkReturnType which adds static types for the whole thunk function. The definition is relatively simple.

import { GlobalState, AllReduxActions } from "./App"

export type ThunkReturnType<
  R = Promise<unknown> | unknown,
  ExtraArgument = any
> =(
  dispatch: <T = Promise<unknown> | unknown>(
    a: AllReduxActions | ThunkReturnType
  ) => T,
  getState: () => GlobalState,
  extraArgument: ExtraArgument
) => R

Our final async thunk function is almost the same as the previous one written in pure Javascript. We just add ThunkReturnType static type for the returned async function.

Now you connected Javascript React Redux App with 100% type-safe Typescript types.

What’s next? 🎉🎉

Well… That’s all!

You have a fully typed Redux application with almost minimum effort of writing types! Anytime you create a new actions/reducers/sub-state/etc… almost all data-types and data-connections are automatically inferred and your code is type-safe, analyzable, and well self-documented.

The full type-safe React Redux app GitHub repo: https://github.com/Svehla/redux-ts-preview

Conclusion

We learned how to use advanced Typescript types and skip redundant static-type definitions. We used Typescript as a static compile-time type checker which infer types from Javascript business logic implementation. In our Redux example, we logically merged reducers with actions, combined-reducers with state and state with selectors. And the top of that, we support to dispatch async actions via the redux-thunks library.

In the diagram below we can see that all functions related to Redux have statically analyzed connections with the rest of the code. And we can use that feature to make consistent APIs between objects and redux functions.

Diagram Legend:
Blue lines — Typescript— **the connections “glue” of functions and objects

I hope that you have read all 3 parts of this series and you slightly changed your mindset on how to write static types in the Javascript ecosystem with the help of awesome tools which Typescript provides to us.

Do you disagree with these Articles? Don’t be afraid to start a conversation below. 💪

You can find the full redux-typescript app in this repository:
https://github.com/Svehla/redux-ts-preview

If you enjoyed reading the article don’t forget to like it.

Typescript generics - stop writing tests & avoid runtime-errors. pt2

Jakub Švehla — Mon, 09 Nov 2020 12:37:32 +0000

TLDR:

This is The second chapter of the series where I show you the way how to avoid runtime-errors without writing tests. We'll use just strong Typescript inferring principles and generics.

You can copy-paste source code from examples into your IDE or online Typescript playground and play with it by yourself.

Chapters:

Inferring
Generics (current read)

In this chapter, we will look at more advanced type inferring and type reusing with Typescript generics.

In the previous chapter about typescript inferring we introduced

type inferring
typeof
&
as const
|

So if you did not read it or you don’t fully understand these concepts or Typescript syntax, check chapter 1.

Generics

Generics are crucial for our new inferring Typescript mindset. It enables us to perform real one-liner Typescript magic. With generics, we will be able to infer whatever we want.

In this chapter, we will introduce

Generics + Type inferring
Type checking using an extends subset
Conditions inside of generics
Type inference in conditional types
Promise wrapper
Utility types
Custom generics utils

I don’t want to duplicate Typescript documentation so you should spend some time reading generics documentation for a better understanding of this series.

You can inspire yourself with useful resources like:

So let’s look at a brief overview of Typescript features which we have to know.

1. Generics + Type inferring

One of the main tools for creating reusable components is generics. We will be able to create a component that can work over a variety of data types rather than a single one.

We can combine generics with Typescript inferring. You can easily create a generic which will be used as the argument of our new function.

const unwrapKey = <T>(arg: { key: T }) => arg.key;

Now we will just call this function and get a type based on implementation.


const unwrapKey = <T>(arg: { key: T }) => arg.key;
// ts infer value1 as string
const value1 = unwrapKey({ key: 'foo' });
// ts infer value1 as boolean
const value2 = unwrapKey({ key: true });
// ts infer value1 as true
const value3 = unwrapKey({ key: true } as const);

Typescript dynamically infers arguments and returns the value of the function by extracting the data type of <T> which is passed as a generic value. The function is 100% type-safe even if the property key is type-agnostic.

Documentation: https://www.typescriptlang.org/docs/handbook/generics.html

2. Type checking using an `extends` subset

The typescript keyword extends works as a subset checker for incoming data types. We just define a set of possible options for the current generic.

const unwrapKey = <T extends boolean | number>(arg: { key: T }) => arg.key;
const ok = unwrapKey({ key: true });

const willNotWork = unwrapKey({
  value: 'value should be boolean or number'
});

Documentation:
https://www.typescriptlang.org/docs/handbook/generics.html#generic-constraints

3. Conditions inside of generics

There is another usage of extends keyword for checking if the type matches the pattern. If it does, Typescript applies a type behind the question mark ?. If not, it uses the type behind the column :. It behaves the same way as the ternary operator in Javascript.

type Foo<T> = T extends number
  ? [number, string]
  : boolean

const a: Foo<number> = [2, '3']
const b: Foo<boolean> = true

If the type of T is a number, the resulting type is a tuple if not, it‘s just boolean.

Documentation:
https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-8.html#conditional-types

This feature can be nicely used with Typescripts type-guards.
https://www.typescriptlang.org/docs/handbook/advanced-types.html#type-guards-and-differentiating-types

4. Type inferring in conditional types

The typescript keyword infer is a more advanced feature. It can infer a type inside of the generic type condition declaration like in the example below.

type ReturnFnType<T> = T extends (...args: any[]) => infer R ? R : any;
const getUser = (name: string) => ({
  id: `${Math.random()}`,
  name,
  friends: [],
})
type GetUserFn = typeof getUser

type User = ReturnType<GetUserFn>

You will read more about ReturnType generic later in this chapter.

I’ll recommend reading the documentation for type inferring in condition types (and usage ofinfer keyword)
https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-8.html#type-inference-in-conditional-types

5. Promise Wrapper

Typescript also perfectly works with Promises

There is a built-in Promise<...> generic which we will use in asynchronous operations. The Promise generic is just a wrapper that wraps your data into Promise “class”.

The Typescript has perfect Promise support for async, await syntax sugar such as:

const getData = () => {
  return Promise.resolve(3)
}

// each async function wrap result into Promise()
const main = async () => {
  // await unwrap Promise wrapper
  const result = await getData()
}

6. Utility types

Typescript provides utility types to simplify common type transformations. These utilities are globally available in your project by default.

Documentation: https://www.typescriptlang.org/docs/handbook/utility-types.html

We will focus on two of them ReturnType<...> and Partial<...>.

6.1 ReturnType<...>

ReturnType is an absolutely phenomenal Typescript feature which we will see in many more examples!

The definition of this generic looks like this:

type ReturnType<T extends (...args: any) => any> =
  T extends (...args: any) => infer R
    ? R
    : any;

As you can see, ReturnType just takes some function and obtains the type of the return value. It enables us to perform more hardcore type inferring. Let’s take a look it in this example

const getUser = (name: string) => ({
  id: Math.random(),
  name,
  isLucky: Math.random() % 2 === 0 
})
type User = ReturnType<typeof getUser>

This is a great feature for our new Typescript inferring programming mental model which we presented in the previous chapter.

Another cool example of ReturnType<...> is getting some specific read-only value from an object inside of a function.

const foo = () => ({ foo: 'bar' } as const);
type FooReturnValue= ReturnType<typeof foo>
type bar = FooReturnValue['foo']

6.2 Partial<…>

In this example, we will use an in keyof syntax feature. If you want to know more about that, read advanced Typescript documentation. https://www.typescriptlang.org/docs/handbook/advanced-types.html#index-types.

Generic Partial definition looks like:

/**
 * Make all properties in T optional
 */
type Partial<T> = {
  [P in keyof T]?: T[P];
};

As you can see, it just wraps a Javascript object and set its keys to be possibly undefined. A question mark after the key name makes the key optional. You can use this generic if you want to use just apart of an object.

const user = {
  id: Math.random(),
  name: 'Foo',
  isLucky: Math.random() % 2 === 0
}

type PartialUser = Partial<typeof user>

7. Custom generics utils

In this section, we are going to create helper generics.

7.1 Await

Await is a utility generic which takes Promise<...> wrapped value and remove the Promise wrapper and leaves only extracted data.

Try to imagine that you already have async Javascript function. As we know, each async function wraps the result into a Promise generic wrapper. So if we call ReturnType for an async function, we get some value wrapped into Promise<T> generic.

We are able to extract a return value out of a Promise using ReturnType<T> and Await<T>:


export type Await<T> = T extends Promise<infer R> ? R : T

// helper function to emit server delay
const delay = (time: number) => {
  return new Promise(res => {
    setTimeout(() => {
      res()
    }, time)
  })

}

const getMockUserFromServer = async () => {
  // some asynchronous business logic 
  await delay(2000)
  return {
    data: {
      user: {
        id: "12",
      }
    }
  }
}

type Response = Await<ReturnType<typeof getMockUserFromServer>>

It adds another possibility of inferring more advanced hidden data types in Javascript code.

7.2 RecursivePartial

This is just enhanced Partial<...> generic which we introduce a few paragraphs ago. The declaration looks like this:

// inspiration: https://stackoverflow.com/a/51365037
type RecursivePartial<T> = {
  [P in keyof T]?:
    // check that nested value is an array
    // if yes, apply RecursivePartial to each item of it
    T[P] extends (infer U)[] ? RecursivePartial<U>[] :
    T[P] extends object ? RecursivePartial<T[P]> :
    T[P];
};

RecursivePartial is initially inspired by this Stack-overflow question https://stackoverflow.com/a/51365037

As you see, it just recursively sets all keys of the nested object to be possibly undefined.

Combine all generics to one monstrous masterpiece

Okay, we learned a lot about Typescript generics. Now we will combine our knowledge together in the next paragraphs.

Imagine that we have an application that makes calls to a backend service. Backend returns data about a currently logged user. For better development, we use mocked responses from the server. Our target is to extract the response data type from mocked API calls (like getMeMock function in the example).

We don’t believe in the correctness of the response from the server so we make all fields optional.

Let’s define our utils generics and just apply a one-line typescript sequence of generics to infer the type of User from the mock function.

// ------------------- utils.ts ----------------------
// inspiration https://stackoverflow.com/a/57364353
type Await<T> = T extends {
  then(onfulfilled?: (value: infer U) => unknown): unknown;
} ? U : T;
// inspiration: https://stackoverflow.com/a/51365037
type RecursivePartial<T> = {
  [P in keyof T]?:
    T[P] extends (infer U)[] ? RecursivePartial<U>[] :
    T[P] extends object ? RecursivePartial<T[P]> :
    T[P];
};


// helper function to emit server delay
const delay = (time: number) => new Promise((res) => {
  setTimeout(() => {
    res();
  }, time);
});


// ----------------- configuration.ts ---------------
const USE_MOCKS = true as const;
// ----------------- userService.ts -----------------
const getMeMock = async () => {
  // some asynchronous business logic
  await delay(2000);
  return {
    data: {
      user: {
        id: '12',
        attrs: {
          name: 'user name'
        }
      }
    }
  };
};
const getMe = async () => {                     
  // TODO: call to server
  return getMeMock();
};

type GetMeResponse = Await<ReturnType<typeof getMeMock>>


type User = RecursivePartial<GetMeResponse['data']['user']>

Do you see it too? We took almost pure javascript code and using our Typescript utils, we added only 2 lines of Typescript code and inferred all static data types from this Javascript implementation! We can still write Javascript code and enhance it with Typescript micro annotations. All of that with a minimal amount of effort without boring interface typing.

And at top of it, every time you want to access some sub-property of User type, your IDE will automatically add an optional chaining operator (name*?* ). Because we made all fields optional, accessing nested values can’t throw a new error.

If optional chaining does not work, you have to set up “strictNullChecks”: true, in your tsconfig.json

And that’s it! At this moment you’re able to infer whatever you want from your Javascript implementation and you’re able to use a type-safe interface without extra static types.

Pay attention! Don’t overuse Generics!

Everytime you manually pass a static type as a parameter into a generic your code starts to smell

— — Jakub Švehla — —

I believe that in your average code there are not big tricky functions with hard to understand data models. So please, don’t overthink your generics. Every time you create new generic think about if it’s necessary to create that kind of redundant abstraction which decreases code/type readability. So if you write a type by hand, be strict and clear. Generics are awesome especially for some general-purpose utility types (ReturnType, Await, Etc.). But be aware, generics in your custom data model could add extra unwanted complexity. So pay attention and use your brain and heart to do it well ❤️.

*Bad practice *😒

type UserTemplate<T> = { id: string, name: string } & T
type User1 = UserTemplate<{ age: number }>
type User2 = UserTemplate<{ motherName: string }>
type User = User1 | User2

*Good practice *🎉

type UserTemplate = { id: string, name: string }
type User1 = UserTemplate & { age: number }
type User2 = UserTemplate & { motherName: string }
type User = User1 | User2

An alternative notation for the good practice 🎉

type User = {
  id: string,
  name: string
} & (
    { age: number }
  | { motherName: string }
)

Conclusion

In chapter one we learned the basics of Typescript and its features. We have new ideas about using static type inferring for Javascript.

In this chapter, we learned how to use generics, and when it’s appropriate to use them.

Do You want more?

If you're interested in more advanced type usage, look to my other articles.

`Object.fromEntries<T>`

Retype Object.fromEntries to support all kinds of tuples
https://dev.to/svehla/typescript-object-fromentries-389c

`DeepMerges<T, U>`

How to implement DeepMerge for static types
https://dev.to/svehla/typescript-how-to-deep-merge-170c

If you enjoyed reading the article don’t forget to like it to tell me that it makes sense to continue.

Typescript inferring - stop writing tests & avoid runtime-errors. pt1

Jakub Švehla — Mon, 09 Nov 2020 12:37:13 +0000

TLDR:

This is the first chapter of the series where I show you the way how to avoid runtime-errors without writing static types and tests using strong Typescript inferring principles.

You can copy-paste source code from examples into your IDE or online Typescript playground and play with it by yourself.

“Minimalist Typescript” chapters:

Inferring (current read)
Generics

Introduction

The whole article series is about changing the Typescript mindset on how to use minimalistic static-types in modern Javascript projects. The problem with Typescript is that when programmers discover static-types they start to overuse and over-engineer them. This results in transforming our beloved Javascript into a language similar to C# or Java.

We’re going to try to forget standard type-safe interface best practices where programmers have to create type interface APIs for everything and then implement business logic compatible with these interface declarations. We can see that in the diagram below where two modules (you can also imagine function etc..)communicate via some abstract interface in the middle.

## approach 1

                     +-------------+
                     |  interface  |
            +--------+-----+-------+-----------+
            |              |                   |
            |              |                   |
    +-------v----+         |            +------v------+
    |   module 1 |         |            |  module 2   |
    |            |         |            |             |
    +------------+         |            +-------------+
                           |

Ughh… We are Javascript developers and we love dynamic prototyping, that is the reason why the diagram does not look very nice to me. I want to have a type-safe code without runtime errors but at the top of it. I don’t want to write static-types by hand at all. The good news is that Typescript has tools that can help us to “obtain” static-types (known as inferring) from pure Javascript implementation. And that's it. Inferring is the key to this whole Typescript series.

Type Inferring enables the compiler to generate type interfaces in the compile-time and check the correctness of our implementation. We will be able to use inferring for creating logical connections between layers of programming abstraction (like functions/files/and so on).
The final code should be type-safe without writing extra type interface APIs like in the diagram below.

## approach 2

    +---------------+   interface 2   +----------------+
    |               +---------------> |                |
    |               |                 |                |    
    | module 1      |    interface 1  |  module 2      |
    |               |                 |                |
    |               | <---------------+                |
    +---------------+                 +----------------+

Our goal is to alter our mindset to think that we will just continue with writing our good old dynamic Javascript. But we will get an extra type-safe layer based on our implementation.

Let’s change the mindset!

Do you remember when you were 15 and started to learn C?

int main() {
  int a = 3;
  int b = 4; 
  int c = a + b;
  return 0;
}

I don’t like that I have to define that a variable c is an integer because it’s obvious! Variables a and b are integers so a + b should return integer too!

We can forgive this behavior because C is almost 50 years old and a low-level programming language that is not suitable for quick prototyping in the application layer but It’s fast as hell.

Remove redundant data types

Let’s look at how can we write strongly-typed Javascript and avoid writing redundant type annotations.

First of all, we are going to rewrite the previous C function into Typescript exactly the same way.

const main = (): number => {
  const a: number = 3
  const b: number = 4
  const c: number = a + b
  return c
}

Ugh… awful right?
Hmm so let’s apply Typescript “type inference”.

const main = () => {
  const a = 3
  const b = 4
  const c = a + b
  return c
}

This looks way better. Typescript is smart and understands that 3 is a number and plus operator returns a number.

Type inferring is a Typescript feature that can “obtain” (infer) data types from your code implementation. As you can see in the demo, Typescript checks the code, infers types of variables, and performs static analyses. The beauty of that solution is that 100% of your code is pure Javascript just enhanced by static-type checking.

Advanced Typescript “inferring”

This is a crucial feature that separates Typescript from other type-safe programming languages.

The problem with pure Javascript started with an escalating number of lines of code. Your brain (and unit tests😃) is just a thin layer that has to check if your newly implemented refactored data structures are compatible with the rest of your code. When you are done with your code you have to check that your documentation is compatible with your latest implementation.

Typescript can fully work like your brain and perform static analyses of code without extra typing by hand. For example, you may write code like:

const foo = ({ bar, baz }) => [bar, baz]

You as a programmer have no idea what type of bar and baz are. Obviously, Typescript has no idea about that as well.

Let’s compare the previous example with the next one:

const main = () => {
  const bar = 3
  const baz = 4
  const foo = { bar, baz } 
  return [foo.bar, foo.baz]
}

It’s much clearer in this more “spaghetti-like” implementation. Variables foo and bar are just numbers.

Don’t forget that if your code contains many “redundant” layers of abstraction, code readability rapidly decreases. In the first example, our brain had no idea what variables bar and baz were.

Many people start to get frustrated with incomprehensible, unclear code, and start to write functions with type interfaces like this one:

type FooArg = {
  bar: number,
  baz: number
}
const foo = ({ bar, baz }: FooArg) => [bar, baz]]

In this example, we add an extra 4 lines just for typing an interface of the foo micro function. Then the code grows, the codebase starts to get less flexible and you have just lost the flexibility of Javascript.

The best statically analyzed code without type defining is the spaghetti one!

— — Jakub Švehla — —

Skip redundant interface definition — use `typeof`

Do you know the DRY (Don’t repeat yourself) programming philosophy?
Every time you create a type interface with defined keys and so on, you start to duplicate your code (and one cat will die).

const user = {
  id: 3,
  name: 'Foo'
}

type User = {
  id: number
  name: string
}
const user: User = {
  id: 3,
  name: 'Foo'
}

We can solve this issue with the Typescript typeof type guard, which takes a Javascript object and infers data types from it.

const user = {
  id: 3,
  name: 'Foo'
};
type User = typeof user

You can see that this new code does not create declaration duplicates and our Javascript object is the source of truth for the type User. And at the top of it, we can still use Typescript types to check the correctness of the code implementation.

The next example demonstrates how type-checking finds an issue in the code using just 2 lines of Typescript code.

const user = {
  id: 3,
  name: 'Foo'
};
type User = typeof user
const changeUserName = (userToEdit: User, age: number) => {
  userToEdit.name = age;
};

If Typescript is not able to 100% correctly infer your static types, you can help the compiler by defining a sub-value of an object with as syntax. In this example: state: 'nil' as 'nil' | 'pending' | 'done' we set that the state attribute contains only nil, pending or done value.

const user = {
  id: 3,
  name: 'Foo',
  // Help the compiler to correctly infer string as the enum optional type
  state: 'nil' as 'nil' | 'pending' | 'done'
};
type User = typeof user
const changeUserName = (useToEdit: User, newName: string) => {
  useToEdit.name = newName;
  useToEdit.state = 'pendingggggg';
};

as you can see:

the only place where you have to define static types by hand are just function arguments

and the rest of the code can be inferred by the Typescript compiler. If you want to be more strict with inferring you can help the Typescript compiler by using the as keyword and write a more strict type inferring Javascript code.

You should not forget that a newly defined function outside of the previous function scope is just another “reusable” layer of abstraction which decreases compiler & human readability and simplicity.

Algebraic data type — Enumerated values

One of the best features of Typescript is Pattern matching based on enumerated values.

Let’s have 3 types of animals. Each kind of animal has different attributes. Your target is to create the custom print function differently for each of your animals.

Your data model layer could look like:


const elephantExample = {
  trunkSize: 10,
  eyesColor: 'red'
}
const pythonExample = {
  length: 50
}
const whaleExample = {
  volume: 30
}

First of all, we can simply get static types from values by using the typeof keyword.

type Elephant = typeof elephantExample
type Python = typeof pythonExample
type Whale = typeof whaleExample
type Animal = 
  | Elephant
  | Python
  | Whale

Let’s add a type attribute for each of our animals to make a unique standardized way of identifying an “instance” of the animal type and check the correctness of objects.

// & operator merge 2 types into 1
type Elephant = typeof elephantExample & { type: "Elephant" }
type Python = typeof pythonExample & { type: "Python" }
type Whale = typeof whaleExample & { type: "Whale" }
type Animal = 
  | Elephant
  | Python
  | Whale
const animalWhale: Animal = {
  type: "Whale",
  volume: 3
}
const animalWhaleErr: Animal = {
  length: 100,
  type: "Whale",
}

You can see that we use the Typescript & operator for merging two Typescript’s data types.

Now we can create a print function that uses a switch-case pattern matching over our inferred javascript object.

const elephantExample = {
  trunkSize: 10,
  eyesColor: 'red'
}
const pythonExample = {
  length: 50
}
const whaleExample = {
  volume: 30
}

// & operator merge 2 types into 1
type Elephant = typeof elephant & { type: "Elephant" }
type Python = typeof python & { type: "Python" }
type Whale = typeof whale & { type: "Whale" }

type Animal = 
  | Elephant
  | Python
  | Whale

const printAnimalAttrs = (animal: Animal) => {
  // define custom business logic for each data type
  switch (animal.type) {
    case 'Elephant':
      console.log(animal.trunkSize)
      console.log(animal.eyesColor)
      break
    case 'Python':
      console.log(animal.size)
      break
    case 'Whale':
      console.log(animal.volume)
      break
  }
}

As you see in this example, we just took a simple Javascript code and added a few lines of types for creating relations between data structures and function arguments. The beauty of that solution is that Typescript does not contain business logic or *data shape declaration so Javascript code is **the only source of truth*. Typescript still checks 100% of your source code interface compatibility and adds a nice self-documentation feature.

Use `as const` for constant values

Typescript has an as const syntax feature that helps with defining constant values instead of basic data types. If the Typescript compiler found an expression like:

it obviously infers justifyContent key as a string. But we as programmers know that justifyContent is an enum with values:
'flex-start' | 'flex-end' | 'start' | .. | .. | etc ...

We have no option of getting this justifyContent data-type information from the code snippet because CSS specification is not related to the Typescript specification. So let’s transform this static object into a type with exact compile-time values. To do this, we are going to use an as const expression.

Now we can use justifyContent as a readonly constant value flex-start.

In the next example, we combine as const, as, and typeof for a one-line configuration type interface.

Conclusion

In this chapter, we went through the basics of Typescript smart inferring. We used Typescript as a type-safe glue for our Javascript code. We were also able to get perfect IDE help and documentation with a minimal amount of effort.

We learned how to:

Infer and check basic data types.
Add static types for arguments of a function.
Use typeof for inferring Typescript types from a static Javascript implementation.
Merge type objects with & operator.
Make options types with | operator.
Use switch-case pattern matching on different data types.
Use as {{type}} for correcting inferred data types.
Use as const for type values.

Next chapter:

In chapter 2, we will look at more advanced type inferring and type reusing with Typescript generics. In the second part of the article, we will declare custom generics for “inferring” from external services.

If you enjoyed reading the article don’t forget to like it to tell me that it makes sense to continue.

How to add types for Object.fromEntries

Jakub Švehla — Sat, 07 Nov 2020 21:16:15 +0000

Step by step tutorial on how to create a proper type for Object.fromEntries() which can work with tuples and read-only data structures.

TLDR:

Source code for Object.fromEntries type generic is at bottom of the article.
You can copy-paste it into your IDE and play with it.

VS-code preview




const data = [
  ['key1', 'value1' as string],
  ['key2', 3]
]  as const

const result = Object.fromEntries(data)

Motivation

The default typescript type for Object.fromEntries definition looks like this



interface ObjectConstructor {
  // ...
  fromEntries(entries: Iterable<readonly any[]>): any;
}

As you can see the usage of return value : any it's not the best one. So we will redeclare static types for this method via the usage of the strongest Typescript tools which are described below.

Prerequisite

before we will continue we have to know the typescript keyword infer and some basic generics usage.
https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-8.html#type-inference-in-conditional-types

If you want to deep dive into advanced typescript types I recommend this typescript series full of useful examples.

Basic static types inferring: https://dev.to/svehla/typescript-inferring-stop-writing-tests-avoid-runtime-errors-pt1-33h7
More advanced generics https://dev.to/svehla/typescript-generics-stop-writing-tests-avoid-runtime-errors-pt2-2k62

Let's start hacking

First of all, we will define Cast<X, Y> generic which helps us to build our target FromEntries<T> type.

`Cast<X, Y>`

This generic help us to bypass the typescript compiler for passing invalid types. We will use Cast<X, Y> to "shrink" a union type to the other type which is defined as the second parameter.



type Cast<X, Y> = X extends Y ? X : Y

Preview



type T4 = string | number
type T5 = Cast<T4, string>

Okay... it should be enough for this moment. We can start with the FromEntries<T> generic.

`FromEntries<T>`

So let's define a new type FromEntriesV1<T>. It takes one argument T and checks if the argument is a two-dimensional matrix [any, any][] if yes, create proper type. if no return default behavior which just returns unknown untyped Object { [key in string]: any }.



type FromEntriesV1<T> = T extends [infer Key, any][]
  // Cast<X, Y> ensure TS Compiler Key to be of type `string`
  ? { [K in Cast<Key, string>]: any }
  : { [key in string]: any }



type ResFromEV1 = FromEntriesV1<[
  ['key1', 'value1'],
  ['key2', 3],
]>

It works the same even without Cast<Key, string> generic but Typescript compiler still warning you that there is a potential error so we have to bypass it with the Cast<X, Y>

This generic works thanks to infer which extracts out all keys into a union type which is used as target object keys.

Now we have to set the correct values of the object but before we will do it let's introduce another generics ArrayElement<A>.

`ArrayElement<A>`

this simple generic helps us to extract data outside of an Array<T> wrapper.



export type ArrayElement<A> = A extends readonly (infer T)[]
  ? T
  : never

Preview



type T1 = ArrayElement<['foo', 'bar']>



const data = ['foo', 'bar'] as const
type Data = typeof data
type T2 = ArrayElement<Data>

Okey we can continue with adding proper value into the new object. We just simply set that value is second item of nested tuple ArrayElement<T>[1].



type FromEntriesV2<T> = T extends [infer Key, any][]
  ? { [K in Cast<Key, string>]: ArrayElement<T>[1] }
  : { [key in string]: any }

we successfully extracted all possible values but as we can see, there is a missing connection between key and value in our new type.

If we want to fix it we have to know another generic Extract<T>. Extract<T> is included in the official standard typescript library called utility-types.

This generic is defined as:



type Extract<T, U> = T extends U ? T : never;

official documentation: https://www.typescriptlang.org/docs/handbook/utility-types.html#extracttype-union

Thanks to this generic we can create connections between keys and values of nested tuples



type FromEntries<T> = T extends [infer Key, any][]
  ? { [K in Cast<Key, string>]: Extract<ArrayElement<T>, [K, any]>[1] }
  : { [key in string]: any }

Preview



type Result = FromEntries<[
  ['key1', 'value1'],
  ['key2', 3],
]>

And... that's all!!! Good job! we did it 🎉 now the generics can transfer an Array of tuples into object type.

Oh, wait. there is still some major issues which we should solve

Generic does not work well with readonly Notations like in the example below



const data = [['key1', 1], ['key2', 2]] as const
type Data = typeof data
type Res = FromEntries<Data>

To resolve this issue let's introduce another generic DeepWriteable

`DeepWriteable<T>`

this generic is used to recursively remove all readonly notations from the data type.
If you create type by typeof (data as const) all keys start with the readonly prefix so we need to remove it to make all objects consistent.



type DeepWriteable<T> = { -readonly [P in keyof T]: DeepWriteable<T[P]> }

Preview



const data = ['foo', 'bar'] as const
type Data = typeof data
type T3 = DeepWriteable<Data>

With this new knowledge, we can fix unexpected behavior and make it all works again.



const data = [['key1', 1], ['key2', 2]] as const
type Data = typeof data

type T6 = FromEntries<DeepWriteable<Data>>

Final source code + Redeclare global Object behavior

If you don't know what declare {module} annotations in typescript is, You can check official documentation https://www.typescriptlang.org/docs/handbook/modules.html

We will use this feature to redeclare the global type behavior of Object.fromEntries.

All you need to do is just paste the code below to your index.d.ts or global.d.ts.




export type ArrayElement<A> = A extends readonly (infer T)[] ? T : never;
type DeepWriteable<T> = { -readonly [P in keyof T]: DeepWriteable<T[P]> };
type Cast<X, Y> = X extends Y ? X : Y
type FromEntries<T> = T extends [infer Key, any][]
  ? { [K in Cast<Key, string>]: Extract<ArrayElement<T>, [K, any]>[1]}
  : { [key in string]: any }

export type FromEntriesWithReadOnly<T> = FromEntries<DeepWriteable<T>>


declare global {
   interface ObjectConstructor {
     fromEntries<T>(obj: T): FromEntriesWithReadOnly<T>
  }
}

And voilá 🎉 🎉 🎉 🎉 🎉 🎉
We are done

I hope that you enjoyed this article the same as me and learned something new. If yes don't forget to like this article

How to deep merge in Typescript

Jakub Švehla — Sat, 07 Nov 2020 09:56:07 +0000

Step by step tutorial on how to create Typescript deep merge generic type which works with inconsistent key values structures.

TLDR:

Source code for DeepMergeTwoTypes generic is at bottom of the article.
You can copy-paste it into your IDE and play with it.

you can play with the code here

Or check the GitHub repo https://github.com/Svehla/TS_DeepMerge



type A = { key1: { a: { b: 'c' } }, key2: undefined }
type B = { key1: { a: {} }, key3: string }
type MergedAB = DeepMergeTwoTypes<A, B>

Prerequisite

If you want to deep dive into advanced typescript types I recommend this typescript series full of useful examples.

Basic static types inferring: https://dev.to/svehla/typescript-inferring-stop-writing-tests-avoid-runtime-errors-pt1-33h7
More advanced generics https://dev.to/svehla/typescript-generics-stop-writing-tests-avoid-runtime-errors-pt2-2k62

Typescript `&` operator behavior problem

First of all, we’ll look at the problem with the Typescript type merging. Let’s define two types A and B and a new type MergedAB which is the result of the merge A & B.



type A = { key1: string, key2: string }
type B = { key1: string, key3: string }

type MergedAB = (A & B)['key1']

Everything looks good until you start to merge inconsistent data types.



type A = { key1: string, key2: string }
type B = { key2: null, key3: string }

type MergedAB = (A & B)

As you can see type A define key2 as a string but type B define key2 as a null value.

Typescript resolves this inconsistent type merging as type never and type MergedAB stops to work at all. Our expected output should be something like this



type ExpectedType = {
  key1: string | null,
  key2: string,
  key3: string
}

Step-by-step Solution

Let’s created a proper generic that recursively deep merge Typescript types.

First of all, we define 2 helper generic types.

`GetObjDifferentKeys<>`



type GetObjDifferentKeys<
  T,
  U,
  T0 = Omit<T, keyof U> & Omit<U, keyof T>,
  T1 = {
    [K in keyof T0]: T0[K]
  }
 > = T1

this type takes 2 Objects and returns a new object contains only unique keys in A and B.



type A = { key1: string, key2: string }
type B = { key2: null, key3: string }

type DifferentKeysAB = (GetObjDifferentKeys<A, B>)['k']

`GetObjSameKeys<>`

For the opposite of the previous generic, we will define a new one that picks all keys which are the same in both objects.



type GetObjSameKeys<T, U> = Omit<T | U, keyof GetObjDifferentKeys<T, U>>

The returned type is an object.



type A = { key1: string, key2: string }
type B = { key2: null, key3: string }
type SameKeys = GetObjSameKeys<A, B>

All helpers functions are Done so we can start to implement the main DeepMergeTwoTypes generic.

`DeepMergeTwoTypes<>`



type DeepMergeTwoTypes<
  T,
  U, 
  // non shared keys are optional
  T0 = Partial<GetObjDifferentKeys<T, U>>
    // shared keys are required
    & { [K in keyof GetObjSameKeys<T, U>]: T[K] | U[K] },
  T1 = { [K in keyof T0]: T0[K] }
> = T1

This generic finds all nonshared keys between object T and U and makes them optional thanks to Partial<> generic provided by Typescript. This type with Optional keys is merged via & an operator with the object that contains all T and U shared keys which values are of type T[K] | U[K].

As you can see in the example below. New generic found non-shared keys and make them optional ? the rest of keys is strictly required.



type A = { key1: string, key2: string }
type B = { key2: null, key3: string }
type MergedAB = DeepMergeTwoTypes<A, B>

But our current DeepMergeTwoTypes generic does not work recursively to the nested structures types. So let’s extract Object merging functionality into a new generic called MergeTwoObjects and let DeepMergeTwoTypes call recursively until it merges all nested structures.



// this generic call recursively DeepMergeTwoTypes<>

type MergeTwoObjects<
  T,
  U, 
  // non shared keys are optional
  T0 = Partial<GetObjDifferentKeys<T, U>>
  // shared keys are recursively resolved by `DeepMergeTwoTypes<...>`
  & {[K in keyof GetObjSameKeys<T, U>]: DeepMergeTwoTypes<T[K], U[K]>},
  T1 = { [K in keyof T0]: T0[K] }
> = T1

export type DeepMergeTwoTypes<T, U> =
  // check if generic types are arrays and unwrap it and do the recursion
  [T, U] extends [{ [key: string]: unknown}, { [key: string]: unknown } ]
    ? MergeTwoObjects<T, U>
    : T | U

PRO TIP: You can see that in the DeepMergeTwoTypes an if-else condition we merged type T and U into tuple [T, U] for verifying that both types passed successfully the condition (similarly as the && operator in the javascript conditions)

This generic checks that both parameters are of type { [key: string]: unknown } (aka Object). If it’s true it merges them via MergeTwoObject<>. This process is recursively repeated for all nested objects.

And voilá 🎉 now the generic is recursively applied on all nested objects
example:



type A = { key: { a: null, c: string} }
type B = { key: { a: string, b: string} }

type MergedAB = DeepMergeTwoTypes<A, B>

Is that all?

Unfortunately not… Our new generic does not support Arrays.

Add arrays support

Before we will continue we have to know the keyword infer.

infer look for data structure and extract data type which is wrapped inside of them (in our case it extract data type of array) You can read more about infer functionality there:
https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-8.html#type-inference-in-conditional-types

Let's define another helper generics!

`Head<T>`

Head This generic takes an array and returns the first item.



type Head<T> = T extends [infer I, ...infer _Rest] ? I : never

type T0 = Head<['x', 'y', 'z']>

`Tail<T>`

This generic takes an array and returns all items exclude the first one.



type Tail<T> = T extends [infer _I, ...infer Rest] ? Rest : never

type T0 = Tail<['x', 'y', 'z']>

That is all we need for the final implementation of arrays merging Generic, so let's hack it!

`Zip_DeepMergeTwoTypes<T, U>`

Zip_DeepMergeTwoTypes is a simple recursive generic which zip two arrays into one by combining their items based on the item index position.



type Head<T> = T extends [infer I, ...infer _Rest] ? I : never
type Tail<T> = T extends [infer _I, ...infer Rest] ? Rest : never

type Zip_DeepMergeTwoTypes<T, U> = T extends []
  ? U
  : U extends []
  ? T
  : [
      DeepMergeTwoTypes<Head<T>, Head<U>>,
      ...Zip_DeepMergeTwoTypes<Tail<T>, Tail<U>>
  ]

type T0 = Zip_DeepMergeTwoTypes<
  [
    { a: 'a', b: 'b'},
  ],
  [
    { a: 'aaaa', b: 'a', c: 'b'},
    { d: 'd', e: 'e', f: 'f' }
  ]
>

Now we'll just write 2 lines long integration in the DeepMergeTwoTypes<T, U> Generic which provides zipping values thanks to Zip_DeepMergeTwoTypes Generic.



export type DeepMergeTwoTypes<T, U> =
  // ----- 2 added lines ------
  // this line ⏬
  [T, U] extends [any[], any[]]
    // ... and this line ⏬
    ? Zip_DeepMergeTwoTypes<T, U>
    // check if generic types are objects
    : [T, U] extends [{ [key: string]: unknown}, { [key: string]: unknown } ]
      ? MergeTwoObjects<T, U>
      : T | U

And…. That’s all!!! 🎉

We did it! Values are correctly merged even for nullable values, nested objects, and long arrays.

Let’s try it on some more complex data



type A = { key1: { a: { b: 'c'} }, key2: undefined }
type B = { key1: { a: {} }, key3: string }


type MergedAB = DeepMergeTwoTypes<A, B>

Full source code



type Head<T> = T extends [infer I, ...infer _Rest] ? I : never
type Tail<T> = T extends [infer _I, ...infer Rest] ? Rest : never

type Zip_DeepMergeTwoTypes<T, U> = T extends []
  ? U
  : U extends []
  ? T
  : [
      DeepMergeTwoTypes<Head<T>, Head<U>>,
      ...Zip_DeepMergeTwoTypes<Tail<T>, Tail<U>>
  ]


/**
 * Take two objects T and U and create the new one with uniq keys for T a U objectI
 * helper generic for `DeepMergeTwoTypes`
 */
type GetObjDifferentKeys<
  T,
  U,
  T0 = Omit<T, keyof U> & Omit<U, keyof T>,
  T1 = { [K in keyof T0]: T0[K] }
 > = T1
/**
 * Take two objects T and U and create the new one with the same objects keys
 * helper generic for `DeepMergeTwoTypes`
 */
type GetObjSameKeys<T, U> = Omit<T | U, keyof GetObjDifferentKeys<T, U>>

type MergeTwoObjects<
  T,
  U, 
  // non shared keys are optional
  T0 = Partial<GetObjDifferentKeys<T, U>>
  // shared keys are recursively resolved by `DeepMergeTwoTypes<...>`
  & {[K in keyof GetObjSameKeys<T, U>]: DeepMergeTwoTypes<T[K], U[K]>},
  T1 = { [K in keyof T0]: T0[K] }
> = T1

// it merge 2 static types and try to avoid of unnecessary options (`'`)
export type DeepMergeTwoTypes<T, U> =
  // ----- 2 added lines ------
  [T, U] extends [any[], any[]]
    ? Zip_DeepMergeTwoTypes<T, U>
    // check if generic types are objects
    : [T, U] extends [{ [key: string]: unknown}, { [key: string]: unknown } ]
      ? MergeTwoObjects<T, U>
      : T | U

you can play with the code here

Or check the GitHub repo https://github.com/Svehla/TS_DeepMerge

And what's next?

If you're interested in another advanced usage of the Typescript type system, you can check these step-by-step articles/tutorials on how to create some advanced Typescript generics.

🎉🎉🎉🎉🎉

Forem: Jakub Švehla

Rethink JS Classes: Embrace Closures for Lightweight State & Typing

🎯 Why Closures over Classes?

👶 Example: Basic Instance

🧠 Type Inference Magic

🧍‍♂️ Singleton Instance

📐 Interfaces

problems with understanding .prototype. or __proto__?

🔗 Namespaced Static Methods with Cross-References

😵‍💫 Binding this?

🏗️ Class Builder

✅ Benefits

🧨 Possible downsides?

🧰 Bonus: Context Builder with AsyncLocalStorage

✅ How to use it

🧲 Bonus #2: Reference Serializer with Internal WeakMap

✅ How to use it

TypeScript or F#?!? WHICH IS BETTER?!

Comparison categories

1. Data-type inferring

2. Generic inferring

3. Dynamic object types

4. Null pointer exceptions

5. Pattern matching

Modules import system

7. Runtime optimization

8. Not owned by mega-corporate

Final conclusion

Is there a solution?

Typed express with generated swagger docs

Typed Express swagger-docs

TLDR:

Package usage preview

Motivation

Patterns used in the package API

SSOT / DRY

Decorators vs Higher order functions

Package future?

What do you think?

Why reflect-metadata suc*s

TLDR:

Good code

Bad code

And... what is reflect-metadata?

Decorators

reflect-metadata

And where is the problem?

Reflect-metadata vs single source of truth (SSOT)?

The solution

JSON Schema vs Class-based schema

Let's go deeper, Infer type from the Javascript schema!

Validators

Use High-order-functions vs Decorators API

Decoration API

HOF (high-order-function) API

Who should care about this article the most?

Is there some good library too?

1. Typed-env-parser

2. Yup

Well That's all...

React typed state management under 10 lines of code

Goal

TLDR:

Historical background

Custom state management Wrapper

Full example

World-first Static time RegEx engine with O(0) time complexity

What the heck is that?

I'm not kidding!!! This is not just a dream!

Disclaimer

Motivation + usage

How does the RegEx engine work under the hood?

1. Tokenizer

2. Parser

3. RegEx Interpreter

And what's next?

How to UPPER_CASE to camelCase in raw Typescript generics

TLDR:

Let's deep dive into code

Letters mapper

problems with understanding `.prototype.` or `proto`?

😵‍💫 Binding `this`?

And... what is `reflect-metadata`?

Async actions with `redux-thunk`

2. Type checking using an `extends` subset

`Object.fromEntries<T>`

`DeepMerges<T, U>`

Skip redundant interface definition — use `typeof`

Use `as const` for constant values

`Cast<X, Y>`