DEV Community: Zhenghao He

Frontend vs. Backend System Design interviews

Zhenghao He — Sun, 06 Feb 2022 19:54:27 +0000

Context

As I mentioned in my last post, I have been interviewing a lot for the past year - not conducting interviews, I was the candidate being interviewed. Most of the interview processes I had with big tech companies consisted of 1-2 system design rounds depending on the level of the role. Unlike traditional backend-focused system design questions, for which you can find lots of prep resources online such as the famous grokking system design interview or system design primer, I didn’t know what to expect for a frontend-focused system design interview as there are very few resources out there talking about this type of interviews.

Now that I have done a fair amount of system design interviews of both types, I want to give you a summary of what to expect, especially for the frontend ones since I have been mostly working on the frontend side.

Similarities

Both frontend-focused and backend-focused system design interviews share a lot of similarities in terms of the methodology you can adopt to solve the design questions:

starting with gathering system requirements
laying out a clear plan and identifying major distinguishable components of the system
proceeding to end to end api design
talking about optimization

Other kinds of similarities include:

The interviewer is relying on you to drive the presentation. You can't rely on the interviewer to have your back.
While the topics can be either micro or macro, you probably won’t need to actually write code - it is rare to jam some portion of coding in the middle of a system design interview
Unlike scantron school exams, both types will consist of mainly open ended questions. There probably isn’t a checklist of things for you to cover one by one. Nor are you expected to drill deep into all of those. When you realize your interviewer is biased toward a particular part of the system, which they usually do, pivot your focus to that area. Other times you focus on your strengths and lead the conversation.

Differences

During the backend-focused system design interviews, you would spend most of the time talking about things like:

backend/server side architecture, hand waving various backend services/components
discussing which type of database to use and how to aggregate data across different shards
designing SQL table schema
choosing the right the cross-region strategy if your service has a global user base
any other kinds of system characteristics like latency, availability, fault tolerance, etc.

For frontend-focused system design interviews, you would spend most of the time talking about stuff like:

frontend/client side architecture, such as the appropriate rendering pattern to choose - client side rendering, or server side rendering or static generation or something in between?
What kind of data fetching mechanism to use - REST vs. GRAPHQL vs. gRPC and what should the APIs look like?
Specifics about UI components
- a newsfeed which has an infinite scroll behaviour with all the images lazily loaded while ensuring the client side has the aspect ratio of the images upfront to prevent layout shift.
- an autocomplete UI component which fetches search result data incrementally in batches while receiving images from server pushes in parallel.
- a gallery page which pulls images and displays them in the correct order despite the asynchrony that comes with the network requests that might cause them to arrive out of order.
How do you leverage different layers of cache to decrease latency or support offline mode.
if they want to get framework-specific, which is totally possible, they might even ask you to define a particular React components’s props or manage complex state in a React app.

A lot times having one type of system design interviews means you can over simplify the opposite side:

In a backend system design interview, the client-side/frontend is reduced to an API layer - you don’t need to consider all the intricacies of the browser or the pesky rerenders your real-time updates would cause.
In a frontend system design interview, you can treat the backend as a black box and you don’t need to worry about how things like how to scale a database, or how your choice of using web sockets might affect the load balancers because of the need for sticky sessions support.

But again, this is a summary of my experience and depending on who your interviewers are (are they frontend, backend and/or fullstack devs), the scope of the role and which team it is (are you going to be on a frontend team or are you expected to work across the stack and stretch into the backend?) your front end system design interview might be a bit of a hybrid where some aspects of backend system design interviews might come up.

Outside of the differences with the technical topics I needed to dig deep into during the interviews, I found there are two other interesting differences that stand out between the two types:

For frontend system design interviews I was often encouraged to treat the interviewers as the product manager and we spent some time just fleshing out the brief solution for each user story. For the backend system design interviews, we didn’t really get to talk about any user interaction (I am aware that the definition of users of your system might vary, depending on whether it is customer-facing vs. developer-facing)
These two types of system design interviews also differ a lot in terms of estimating certain system's needs based on the potential scale of the system. The system needs can be storage needs or throughput needs or any other types of requirements.
- It is common and expected to do these estimation during backend system design interviews since your design decision is only feasible when all of the system needs can realistically be met.
- But for the frontend system design interview, I rarely needed to do any quantitative estimation - for example, when I was designing some live feed during a frontend system design interview, I didn’t need to do estimations like “So let’s say each message was roughly 140 characters long and it is utf8 so that’s 140 bytes and an average user gets 10000 messages over a certain period of time so we ended up allocating 1.4mb memory on user devices”. Again, I am not saying that this would never come up during a frontend system design interview. in my experience It is just much, much more rare compared to backend ones.

Career Ceiling

I am going to talk about something that is a little tangential. I don't think this is going to be a hot take but if you just want to pass the upcoming interviews, then you are welcome to skip this part.

I have done interviews for both frontend focused roles and general software engineer roles. As I went through the preparation process for the system designs interviews, it just occurred to me that there is indeed a career ceiling for a pure frontend focused software engineer role.

Ok so let’s first get this out of the way - you can be extremely successful as either a frontend dev or a backend dev.

Also it is hard to discuss any topic intelligently when we cannot agree on definitions. By saying frontend devs I meant developers/engineers who solely work on the UI of a software system. And by saying career ceiling I meant the potential terminal title and the highest level such a dev/engineer can achieve in the technical individual contributor track.

This is an unspoken thing and a very impolite conversation. And there are exceptions to this but just statistically speaking there seems to be a career ceiling for frontend-only devs.

Fighting the inertia

Part of the ceiling comes from some traditional baggage:

modern frontend development is fairly new compared to the backend counterpart. I have seen some bias in the industry that frontend is not real engineering compared to the backend and that needs absolutely to be combated.
power structure persists for a very long time and that’s partially why most of VP Eng and CTOs out there are backend/infra devs.

Economic reasoning

I had this realization that when I was going through the backend system design interviews vs. the frontend system design interviews - the technical topics those interviews tend to cover let me think about some economic reasoning leading to the perception of a "Frontend Ceiling” as well. Your value to the company really depends on how many machines/compute/storage run through you. As a dev/engineer, that means much money you control and frontend-only devs just don’t take as much. Of course frontend is just as hard and as important especially for consumer facing products but at the end of the day your compute is being run on someone else’s machine or device and the company just don’t value that as much as the compute that they themselves need to pay for and to scale.

Short-lived vs. Long-running

On top of that, normally the frontend/web apps are short-lived on the client side - the user opens the browser tab that loads your app and after 20 minutes they might just close the tab, and all the memory allocated by your app is on their devices from that point onward. On the other hand, the backend servers/services behind probably keep running for months or even years. One implication resulting from this difference is that you can generally get away with bad code that leads to performance problems down the road in frontend apps because they are short-lived and the scale of the data they are dealing with is probably small, but you cannot ignore that in a long-running backend service.

Good luck with your interviews.

The type hierarchy tree

Zhenghao He — Sun, 06 Feb 2022 19:52:03 +0000

Try read the following TypeScript code snippet and work it out in your head to predicate whether or not there would be any type errors for each assignment:

// 1. any and unknown
let stringVariable: string = 'string'
let anyVariable: any
let unknownVariable: unknown 

anyVariable = stringVariable
unknownVariable = stringVariable
stringVariable = anyVariable
stringVariable = unknownVariable


// 2. `never` 
let stringVariable: string = 'string'
let anyVariable: any
let neverVariable: never

neverVariable = stringVariable
neverVariable = anyVariable
anyVariable = neverVariable
stringVariable = neverVariable


// 3. `void` pt. 1
let undefinedVariable: undefined 
let voidVariable: void
let unknownVariable: unknown

voidVariable = undefinedVariable
undefinedVariable = voidVariable
voidVariable = unknownVariable


// 4. `void` pt. 2

function fn(cb: () => void): void {
    return cb()
}

fn(() => 'string')

If you were able to come up with the correct answers without pasting the code into your editor and let the compiler does its job, I am genuinely going to be impressed. At least I couldn’t get them all right despite writing TypeScript for more than a year. I was really confused by this part of TypeScript which involves types like any, unknown, void and never

I realized I didn’t have the correct mental model for how those types works. Without a consistent and accurate mental model, I could only rely on my experience or intuitions or constant trial and error from playing with the TypeScript compiler.

The blog post is my attempt to introspect and rebuild the mental model of TypeScript’s type system.

A warning up front: this is not a short article. You can jump directly to the section where I explore the type hierarchy tree if you are in a hurry.

It is a hierarchy tree

Turns out all types in TypeScript take their place in a hierarchy. You can visualize it as a tree-like structure. Minimally, in a tree, we can a parent node and a child node. In a type system, for such a relationship, we call the parent node a supertype and the child node a subtype.

You are probably familiar with inheritance, one of the well-known concepts in object-oriented programming. Inheritance establishes an is-a relationship between a child class and a parent class. If our parent class is Vehicle, and our child class is Car, the relationship is “Car is Vehicle”. However it doesn’t work the other way around - an instance of the child class logically is not an instance of the parent class. “Vehicle is not Car”. This is the semantic meaning of inheritance, and it also applies to the type hierarchy in TypeScript.

According to the Liskov substitution principle, instances of Vehicle (supertype) should be substitutable with instances of its child class (subtype) Cars without altering the correctness of the program. In other words, If we expect a certain behavior from a type (Vehicle), its subtypes (Car) should honor it.

I should mention that the Liskov substitution principle is from a 30-year-old paper written for PhD's. There are a ton of nuances to it that I cannot possibly cover in one blog post.

Putting this together, in TypeScript, you can assign/substitute an instance of a type’s subtype to/with an instance of that (super)type, but not the other way around.

By the way I just realize the meaning of the word “substitute” changes radically depending on the preposition that follows it. In this blog post, when I say "substitute A with B”, it means we end up with B instead of A.

nominal and structural typing

There are two ways in which supertype/subtype relationships are enforced. The first one, which most mainstream statically-typed languages (such as Java) use, is called nominal typing, where we need to explicitly declare a type is the subtype of another type via syntax like class Foo extends Bar. The second one, which TypeScript uses is structural typing, which doesn’t require us to state the relationship explicitly in the code. An instance of Foo type is a subtype of Bar as long as it has all the members that Bar type has, even if Foo has some additional members.

Another way to think about this supertype-subtype relationship is to check which type is more strict, type {name: string, age: number} is more strict than the type {name: string} since the former requires more members defined in its instances. Therefore type {name: string, age: number} is a subtype of type {name: string}.

two ways of checking assignability/substitutability

One last thing before we dive into the type hierarchy tree in TypeScript:

type cast: you can just assign a variable of one type to a variable of another type to see if it raises a type error. More on that later.

the extends keyword -you can extend one type to another:

type A = string extends unknown? true : false;  // true
type B = unknown extends string? true : false; // false

the top of the tree

Let's talk about the type hierarchy tree.

In TypeScript, there are two types are that the supertypes of all other types: any and unknown.

They accept any value of any type, encompassing all other types.

This graph is by no means an exhaustive list of all the types that TypeScript has. Check out the source code of TypeScript if you are interested to see all the types that it currently supports.

upcast & downcast

There are two types of type cast - upcast and downcast.

Assigning a subtype to its supertype is called upcast. By the Liskov substitution principle, upcast is safe so the compiler lets you do it implicitly, no questions asked.

There are exceptions where TypeScript disallows the implicit upcast. I will address that at the end of the post.

You can think of upcast similiar to walking up the tree - replacing (sub)types that are more strict with their supertypes that are more generic.

For example, every string type is a subtype of the any type and the unknown type. That means the following assignments are allowed:

let string: string = 'foo'
let any: any = string // ✅ ⬆️upcast
let unknown: unknown = string // ✅ ⬆️upcast

The opposite is called downcast. Think of it as walking down the tree - replacing the (super)type that are more generic with their subtypes that are more strict.

Unlike upcast, downcast is not safe and most strongly typed languages don’t allow this automatically. As an example, assigning variables of the any and unknown type to the string type is downcast:

let any: any
let unknown: unknown
let stringA: string = any // ✅ ⬇️downcast - it is allowed because `any` is different..
let stringB: string = unknown // ❌ ⬇️downcast

When we assign unknown to a string type, the TypeScript complier gives us a type error, which is expected since it is downcast so it cannot be performed without explicitly bypassing the type checker.

However TypeScript would happily allow us to assign any to a string type, which seems contradictory to our theory.

The exception here with any is because, in TypeScript the any type exists to act as a backdoor to escape to the JavaScript world. It reflects JavaScript’s overarching flexibility. Typescript is a compromise. This exception exists not due to some failure in design but the nature of not being the actual runtime language as the runtime language here is still JavaScript.

the bottom of the tree

The never type is the bottom for the tree, from which no further branches extend.

Symmetrically, the never type behaves like the an anti-type of the top types - any and unknow, whereas any and unknown accept all values, never doesn’t accept any value (including values of the any type) at all since it is the subtype of all types.

let any: any 
let number: number = 5
let never: never = any // ❌ ⬇️downcast 
never = number // ❌ ⬇️downcast 
number = never // ✅ ⬆️upcast

If you think hard enough, you might have realized that never should have an infinite amount of types and members, as it must be assignable or substitutable to its supertypes, i.e. every other type in the type system in TypeScript according to the Liskov substitution principle. For example, our program should behave correctly after we substitute number and string with never since never is the subtype of both string and number types and it shouldn’t break the behavior defined by its supertypes.

Technically this is impossible to achieve. Instead, TypeScript makes never an empty type (a.k.a an uninhabitable type): a type for which we cannot have an actual value at runtime, nor can we do anything with the type e.g. accessing properties on its instances. The canonical usecase for never is when we want to type a return value from a function that never returns.

A function might not return for several reasons: it might throw an exception on all code paths, it might loop forever because it has the code that we want to run continuously until the whole system is shut down, like the event loop. All these scenarios are valid.

function fnThatNeverReturns(): never {
    throw 'It never returns'
}

const number: number = fnThatNeverReturns() // ✅ ⬆️upcast

The assignment above might seem wrong to you at first - if never is an empty type, why is that we can assign it to a number type? The reason why such an assignment is fine is that the compiler knows that our function never returns so nothing will ever be assigned to the number variable. Types exist to ensure that the data is correct at runtime. If the assignment never actually happens at runtime, and the compiler knows that for sure in advance, then the types don’t matter.

There is another way to produce a never type is to intersect two types that aren’t compatible - e.g. {x: number} & {x: string}.

type Foo = {
    name: string,
    age: number
}
type Bar = {
    name: number,
    age: number
}

type Baz = Foo & Bar

const a: Baz = {age: 12, name:'foo'} // ❌ Type 'string' is not assignable to type 'never'

Edit from the future: I realized that there are some nuances to the resulting type - if disjoint properties are considered as discriminant properties (roughly, those whose values are of literal types or unions of literal types), the whole type is reduced to never. This is a feature introduced in TypeScript 3.9. Check out this PR for details and motivation.

types in between

We have talked about the top types and the bottom type. The types in between are just the other regular types you use everyday - number, string, boolean, composite types like object etc.

There shouldn’t be too much surprise as to how those types work once we have established the correct mental model:

it is allowed to assign a string literal type e.g. let stringLiteral: 'hello' = 'hello' to a string type (upcast) but not the other way around (downcast)

it is allowed to assign a variable holding an object of a type with extra properties to an object of a type with less properties when the existing properties’ types match (upcast) but not the other way around (downcast)

type UserWithEmail = {name: string, email: string}
type UserWithoutEmail = {name: string}

type A = UserWithEmail extends UserWithoutEmail ? true : false // true ✅ ⬆️upcast

Or assign an non-empty object to an empty object:

    const emptyObject: {} = {foo: 'bar'} // ✅ ⬆️upcast

However there is one type I want to talk more about in this section since people often confuse it with the bottom type never and that type is void.

In many other languages, such as C++, void is used as the a function return type that means that function doesn't return. However, in TypeScript, for a function that doesn't return at all, the correct type of the return value is never.

So what is the type void in TypeScript? void in TypeScript is a supertype of undefined - TypeScript allows you to assign undefined to void (upcaset) but again, not the other way around (downcast)

This can also be verified via the extends keyword:

type A = undefined extends void ? true : false;  // true
type B = void extends undefined ? true : false; // false

void is also an operator in javascript that evaluates the expression next to it to undefined, e.g. void 2 === undefined // true.

In TypeScript, the type void is used to indicate that the implementer of a function is making no guarantees about the return type except that it won’t be useful to the callers. This opens the door for a void function at runtime to return something other than undefined, but whatever it returns shouldn’t be used by the caller.

function fn(cb: () => void): void {
    return cb()
}

fn(() => 'string')

At first blush this might seem like a violation for the Liskov substitution principle since the type string is not a subtype of void so it shouldn’t be able to be substitutable for void. However, if we view it from the perspective of whether or not it alters the correctness of the program, then it becomes apparent that as long as the caller function has no business with the returned value from the void function (which is exactly the intended outcome of the void type), it is pretty harmless to substitute that with a function that returns something different.

This is where TypeScript is trying to be pragmatic and complements the way JS works with functions. In JavaScript it is pretty common when we reuse functions in different situations with the return values being ignored.

situations where TypeScript disallows implicit upcast

Generally there are two situations, and to be honest it should be pretty rare to find yourself in these situations:

When we pass literal objects directly to function

function fn(obj: {name: string}) {}

fn({name: 'foo', key: 1}) // ❌ Object literal may only specify known properties, and 'key' does not exist in type '{ name: string; }'

When we assign literal objects directly to variables with explicit types

type UserWithEmail = {name: string, email: string}
type UserWithoutEmail = {name: string}

let userB: UserWithoutEmail = {name: 'foo', email: 'foo@gmail.com'} // ❌ Type '{ name: string; email: string; }' is not assignable to type 'UserWithoutEmail'.

An introduction to type programming in TypeScript

Zhenghao He — Mon, 31 Jan 2022 00:00:00 +0000

See discussions on Hacker News

Types are a complex language of their own

I used to think of TypeScript as just JavaScript with type annotations sprinkled on top of it. With that mindset, I often found writing correct types tricky and daunting, to a point they got in the way of building the actual applications I wanted to build, and frequently, it led me to reach for any. And with any, I lose all type safety.

Indeed, types can get really complicated if you let them. After writing TypeScript for a while, it occurred to me that the TypeScript language actually consists of two sub-languages - one is JavaScript, and the other is the type language. For the JavaScript language, the world is made of JavaScript values; for the type language, the world is made of types. When we write TypeScript code, we are constantly dancing between these two worlds: we create types in our type world and "summon" them in our JavaScript world using type annotations; we can go in the other direction too: use the typeof operator on JavaScript variables/properties to retrieve the corresponding types.

The JavaScript language is very expressive, so is the type language - in fact, the type language is so expressive that it has been proven to be Turing complete.

Here I don't make any value judgment of whether being Turing complete is good or bad, nor do I know if it is even by design or by accident (in fact, often times, Turing-completeness was achieved by accident). My point is the type language itself, as innocuous as it seems, is certainly powerful, highly capable and can perform arbitrary computation at compile time.

When I started to think of the type language in TypeScript as a full-fledged programming language, I realized it even has a few characteristics of a functional programming language:

use recursion instead of iteration
1. in TypeScript 4.5 we have tail call optimized recursion to some extent
types (data) are immutable

In this post, we will learn the type language in TypeScript by comparing it with JavaScript so that you can leverage your existing JavaScript knowledge to master TypeScript quicker.

This post assumes that readers have some familiarity with JavaScript and TypeScript. And if you want to learn TypeScript from scratch properly, you should start with The TypeScript Handbook. I am not here to compete with the docs.

Variable declaration

In JavaScript, the world is made of JavaScript values, and we declare variables to refer to values using keywords var, const and let. For example:

const obj = {name: 'foo'}

In the type language, the world is made of types, and we declare type variables using keywords type and interface. For example:

type Obj = {name: string}

The idea of "type variables" is a made-up concept - a type variable is an alias of a type, analogous to how a JavaScript variable references a value. I found drawing this analogy makes explaining concepts of the type language much easier.

Types and values are very related. A type, at its core, represents the set of possible values. Sometimes the set is finite, e.g., type Name = 'foo' | 'bar', a lot of times the set is infinite, e.g., type Age = number. In TypeScript we integrate types and values and make them work together to ensure that the runtime values match the compile-time types.

Local variable declaration

We talked about how you can create type variables in the type language. However, the type variables have a global scope by default. To create a local type variable, we can use the infer keyword in our type language.

type A = 'foo'; // global scope
type B = A extends infer C ? (
    C extends 'foo' ? true : false// *only* inside this expression, C represents A
) : never

Although this particular way of creating scoped variables might seem strange to JavaScript developers, it actually finds its roots in some pure functional programming languages. For example, in Haskell, we can use the let keyword with in to perform scoped assignments as in let {assignments} in {expression}:

let two = 2; three = 3 in two * three 
//                         ↑       ↑
// two and three are only in scope for the expression `two * three`

Equality comparisons and conditional branching

In JavaScript. we can use ===/== with if statement or the conditional (ternary) operator ? to perform equality check and conditional branching.

In the type language, on the other hand, we use the extends keyword for "equality check", and the conditional (ternary) operator ? for conditional branching too as in:

    TypeC = TypeA extends TypeB ? TrueExpression : FalseExpression

If TypeA is assignable or substitutable to TypeB, then we enter the first branch and get the type from TrueExpression and assign that to TypeC ; otherwise we get the type from FalseExpression as a result to TypeC.

The concept of assignability/substitutability is one of the core concepts in TypeScript that deserves a separate post - I wrote one covering that in detail.

A concrete example in JavaScript:

const username = 'foo'
let matched

if(username === 'foo') {
    matched = true
} else {
    matched = false
}

Translate it into the type language:

type Username = 'foo'
type Matched = Username extends 'foo' ? true : false // true

The extends keyword is versatile. It can also apply constraints to generic type parameters. For example:

function getUserName<T extends {name: string}>(user: T) {
    return user.name
}

By adding the generic constraints, <T extends {name: string}> we ensure the parameter our function takes always consist of a name property of the type string.

Retrieve types of properties by indexing into object types

In JavaScript we can access object properties with square brackets e.g. obj['prop'] or the dot operator e.g., obj.prop.

In the type language, we can extract property types with square brackets as well.

type User = {name: string, age: number}
type Name = User['name']

This works not just with object types, we can also index the type with tuples and arrays.

type Names = string[]
type Name = Names[number]

type Tuple = [string, number]
type Age = Tuple[1]

Functions

Functions are the main reusable “building blocks” of any JavaScript program. They take some input (some JavaScript values) and return an output (also some JavaScript values).
In the type language, we have generics. Generics parameterize types like functions parameterize value. Therefore, a generic is conceptually similar to a function in JavaScript.

For example, in JavaScript:

function fn(a, b = 'world') { return [a, b] }
const result = fn('hello') // ["hello", "world"]

For our type language, we have:

type Fn  <A extends string, B extends string = 'world'>   =  [A, B]
//   ↑    ↑           ↑                          ↑              ↑
// name parameter parameter type          default value   function body

type Result = Fn<'hello'> // ["hello", "world"]

However, generics are by no means a perfect analogy for functions. For one, unlike functions in JavaScript, Generics are not first-class citizens in the type language. That means we cannot pass a generic to another generic like we pass a function to another function as TypeScript doesn't allow generics as type parameters.

Map and filter

In our type language, types are immutable. If we want to modify a part of a type, we have to transform the existing ones into new types. In the type language, the details of iterating over a data structure (i.e. an object type) and applying transformations evenly are abstracted away by Mapped Types. We can use it to implement operations that are conceptually similar to the map and filter array methods in JavaScript.

In JavaScript, let's say we want to transform an object's properties from numbers to strings:

const user = {
    name: 'foo',
    age: 28
}

function stringifyProp(object) {
    return Object.fromEntries(Object.entries(object)
        .map(([key, value]) => [key, String(value)]))
}

const userWithStringProps = stringifyProp(user) // {name:'foo', age: '28'}

In the type langauge, the mapping is done using this syntax [K in keyof T] where the keyof operator gives us property names as a string union type.

type User = {
    name: string,
    age: number
}

type StringifyProp<T> = {
    [K in keyof T]: string
}

type UserWithStringProps = StringifyProp<User> // { name: string; age: string; }

In JavaScript, we can filter out the properties of an object based on some critiria. For example, we can filter out all non-string properties:

const user = {
    name: 'foo',
    age: 28
}

function filterNonStringProp(object) {
    return Object.fromEntries(Object.entries(object)
        .filter(([key, value]) => typeof value === 'string' && [key, value]))
}

const filteredUser = filterNonStringProp(user) // {name: 'foo'}

In our type language, this can be achieved with the as operator and the never type:

type User = {
    name: string,
    age: number
}

type FilterStringProp<T> = {
    [K in keyof T as T[K] extends string ? K : never]: string
}

type FilteredUser = FilterStringProp<User> // { name: string }

There are a bunch of builtin utility “functions” (generics) for transforming types in TypeScript so often times you don't have to re-invent the wheels.

Pattern matching

We can also use the infer keyword to perform pattern matching in the type language.

For example, in a JavaScript program, we can use regex to extract a part of a string:

const str = 'foo-bar'.replace(/foo-*/, '')
console.log(str) // 'bar'

The equivalence in our type language:

type Str = 'foo-bar'
type Bar = Str extends `foo-${infer rest}` ? rest : never // 'bar'

Recursion, instead of iteration

Just like many pure functional programming languages out there, in our type language, there is no syntactical construct for for loop to iterate over a list of data. Recursion take the place of loops.

Let's say in JavaScript, we want to write a function to return an array with same item repeated multiple times. Here is one possible way you can do that:

function fillArray(item, n) {
    const res = [];
    for (let i = 0; i < n; i++) {
        res[i] = item;
    }
    return res;
}

The recurisve solution would be:

function fillArray(item, n, array = []) {
    return array.length === n ? array : fillArray(item, n, [item, ...array])
}

How do we write out the equivalence in our type language? Here are logical steps to arrive at one solution:

create a generic type called FillArray (remember we talked about that generics in our type language are just like functions?)
- FillArray<Item, N extends number, Array extends Item[] = []>
Inside the "function body", we need to check if the length property on Array is already N using the extends keyword.
- if it has reached to N (the base case), then we simply return Array
- if it hasn't reached to N, it recurses and added one more Item into Array

Putting these together, we have:

type FillArray<Item, N extends number, Array extends Item[] = []> 
    = Array['length'] extends N 
        ? Array : FillArray<Item, N, [...Array, Item]>;

type Foos = FillArray<'foo', 3> // ["foo", "foo", "foo"]

Limits for recursion depth

Before TypeScript 4.5, the max recursion depth is 45. In TypeScript 4.5, we have tail call optimization, and the limit increased to 999.

Avoid type gymnastics in production code

Sometimes type programming is jokingly referred to as “type gymnastics” when it gets really complex, fancy and far more sophisticated than it needs to be in a typical application.
For example:

They are more like academic exercises, not suitable for production applications because:

they are hard to comprehend, especially with esoteric TypeScript features.
they are hard to debug due to incredibly long and cryptic compiler error messages.
they are slow to compile.

Just like we have Leetcode for practicing your core programming skills, we have type-challenges for practicing your type programming skills.

Closing thoughts

We have covered a lot in this blog post. The point of this post is not to really teach you TypeScript, rather than to reintroduce the "hidden" type language you might have overlooked ever since you started learning TypeScript.

Type programming is a niche and underdiscussed topic in the TypeScript community, and I don't think there is anything wrong with that - because ultimately adding types is just a means to an end, the end being writing more dependable web applications in JavaScript. Therefore, to me it is totally understandable that people don't often take the time to "properly" study the type language as they would for JavaScript or other programming languages.