Table of Contents

• Stranger Danger of Typescript Generics
  • Sacrificing Readability for... Whatever This Is
  • What About Using The Record Type?
• Scaling Good, Scaling Bad

The gist of [current proposals] is to fold Typescript on itself so that we can tip the scales back in favour of natural, readable code

Stranger Danger of Typescript Generics

Typescript (TS) is one of my three daily-use languages. It was also my road back into web development. As the saying goes: a Typescript server in the palm is worth two Javascript runtimes in the bush.

...Someone just made that up.

But I see easy reasons for people not to want to implement Typescript in their workspace, even as someone who uses and enjoys TS myself. On that note, I was going to unpack TS generics in this post, until I reviewed what I'd written and saw I wasn't saying anything new in 2024 that hasn't been said about generics over the last 4 years.

To recap:

• Generics are promoted as one of Typescript's most powerful tools for shipping reusable code
• Generics can make for unreadable code in no time at all

You can get hooked on coming up with the optimal generic expression that scales efficiently; who wouldn't love to ship a library or component that anyone could plug into their app, with minimal storage footprint?

Just this past week, in support of a library that was migrating to Svelte 5, I came up with this Frankensteiner:

It's not particularly original. It works. Most of all, it's not nice.

I immediately told the library creator that we shouldn't go with that, even though they were up for going ahead with it. By that point, I think they were relieved just to not be hitting Typescript compile errors before they'd come to me for support. But I just had a feeling we'd regret it later down the line if started off with the kind of pattern above.

(Sidenote: you might also consider an entirely different language - Go - if optimised library code is your number one goal).

So we know less lines of code does not automatically mean a readable codebase to save you time in the long run.

Instead of me going back over the dangers of generics that have been well covered for years now, let's talk solutions: Here's a proposal - Meta Type System - on the official TS repository over a year ago.

It's not my proposal and I don't know the author personally; the gist is to abstract Typescript even further (folding it on itself as the next built-in interface layer) so that we can tip the scales back in favour of natural, readable code.

The kind of reusable code you'd thank yourself for writing six months down the line - while also harnessing the power of generic signatures and expressions.

Can we have our cake and eat it? Services like TypeDB that run their own implementation details along these lines, and I hope at least one of these kinds of platforms sees success soon for the future of Typescript.

It's never a free lunch, though.

Typescript is barely a decade old and midway through version 5 - the more built-in layers the language decides to take on board (if it does) the more we risk installing a Typescript standard library that brings both size and abstraction problems the likes of which have hit Python, Java and other great languages.

Anyway, that's it. That's the post.

If you want to read what I'd originally written on Typescript generics, you'll find it below.

Sacrificing Readability for... Whatever This Is

How many static languages do you know where you have to access an object's value by, instead, declaring the object's key?

This kind of counter-intuitive behaviour was Typescript's inheritance from day 1; it had to make allowances for the way Javascript maps key-values pairs under the hood, and those allowances lead to generic expressions this slightly more readable one:

This part of the library ships with a base component that always acceptsta string property. Any spin-off components in that part of the library could accept even more values (of different types) in their properties - depending on the user's needs when plugging it into their own app or service.

The counter-intuitive line begins with [K in T]. In the short-term scheme of things, this isn't a big deal. If you've seen it once, you've seen it ten times that week. You can remind yourself how JS mapping works under the hood: Typescript's anticipating the runtime will map the key K in T expression to its corresponding value V in T to get the number value at runtime. Your goal was really just to make use of the value all along.

It's a pretty backwards way of writing expressions but, as we said, you could retain it in your head if you're doing this stuff day in day out for the next month. Yet what about six months down the line?

What about when a colleague from a different team (like the mobile dev specialist who's spent a long time away from Typescript) is tasked with trying to make sense of your code for the first time?

Your options are:

1. A sticky note as a reminder of where JS maps are kicking in
2. Write even more custom-code around your generics for readability's sake

In either case, Typescript's design is the core problem.

What About Using The Record Type?

I try to use the Record type as often as possible in this context, because I've gotten used to the mainstream patterns around this and I just don't fancy straying too far from the pack in terms of how other developers build in Typescript.

Ideally you'd hope Record would reduce lines of code - and it does - but you mangle utility types like Omit to get the job done. And you wind up back with our very first example:

This single line of code does the exact same job we've been looking to hand out. And in more general terms of "accessing values by referencing their keys", there's the infamous:

to write out a value of that type. But I've made the same point in three different ways now.

Scaling Good, Scaling Bad

The important thing is not to embrace counter-intutive code as if it were its own reward. What looks like an optimisation now may cost you time later.

In my first year of working with Typescript on the daily, I managed to get away with only having to use generics once in the entire year.

In one way, avoiding it was a relief: Frankly, every now and then I see some work online that looks like developers being fancy with generics for the sake of it. There's nothing wrong with a passion for arithmetic, but I'd prefer it doesn't come at the expense of keeping your feet on the ground. Yet there was another warning flag sounding in the back of my head: I'd irrationally begun to feel like TS generics were something to be avoided, when really they're very useful (arguably essential) in this context: Building anything with the intent of scale and re-usability.

You want your shipped library or component to be helpful enough that anyone can plug in whatever properties they need into it from their app or service, and they can get going. When something you've written scales with minimal edge cases falling outside your code coverage... that feels good. Real good.

TS generics can be a fundamental way to that good feeling. So I'd say: don't avoid them.

But I also won't tell you TS generic expressions look good, or that they roll off the tongue. They don't. When people tell me "Typescript just looks ugly" as a language, it's odds on that generics are what they're getting at.

The important thing is not to embrace counter-intutive code as if it were its own reward; not trying to "optimise" an expression if you're making big sacrifices on readability. What looks like an optimisation now may cost you time later. Better to stay readable.