DEV Community

Cover image for A use case for TypeScript Generics
Julian Garamendy
Julian Garamendy

Posted on • Updated on • Originally published at juliangaramendy.dev

A use case for TypeScript Generics

The following may be a bit obvious for some. But something just clicked in my head and I thought I'd write it down.

When generics are a good idea

Imagine we write a function that returns the "oldest" item in a set/array:

function getOldest(items: Array<{ age: number }>) {
  return items.sort((a, b) => b.age - a.age)[0];
}
Enter fullscreen mode Exit fullscreen mode

This function can be called with an array of any kind of objects as long as they contain an age property of type number.

To help reasoning about it, let's give this a name:

type HasAge = { age: number };
Enter fullscreen mode Exit fullscreen mode

Now our function can be annotated like this:

function getOldest(items: HasAge[]): HasAge {
  return items.sort((a, b) => b.age - a.age)[0];
}
Enter fullscreen mode Exit fullscreen mode

Great! Now we can use this function with any objects that conform to the HasAge interface:

const things = [{ age: 10 }, { age: 20 }, { age: 15 }];
const oldestThing = getOldest(things);

console.log(oldestThing.age); // 20 ✅
Enter fullscreen mode Exit fullscreen mode

Because the type of oldestThing is inferred to be HasAge, we can access its .age property.

But what if we have more complex types?

type Person = { name: string, age: number};

const people: Person[] = [
  { name: 'Amir', age: 10 }, 
  { name: 'Betty', age: 20 }, 
  { name: 'Cecile', age: 15 }
 ];

const oldestPerson = getOldest(people); // 🙂 no type errors
Enter fullscreen mode Exit fullscreen mode

This works, but now the inferred type of oldestPerson is HasAge. We've lost the Person type along the way. As a result we can't (safely) access it's .name property.

console.log(oldestPerson.name); // ❌ type error: Property 'name' does not exist on type 'HasAge'.
Enter fullscreen mode Exit fullscreen mode

Annotating oldestPerson:Person won't work:

const oldestPerson: Person = getOldest(people); // ❌ type error
// Property 'name' is missing in type 'HasAge' but required in type 'Person'.
Enter fullscreen mode Exit fullscreen mode

We could use type assertions, but it's not a good idea. (why?)

const oldestPerson = getOldest(people) as Person; // 🚩
console.log(oldestPerson.name); // no type error
Enter fullscreen mode Exit fullscreen mode

You can try this in TypeScript Playground.

Using Generics

We can do better. We can turn this into a generic function.

function getOldest<T extends HasAge>(items: T[]): T {
  return items.sort((a, b) => b.age - a.age)[0];
}

const oldestPerson = getOldest(people); // ✅ type Person
Enter fullscreen mode Exit fullscreen mode

Success!! Now the inferred type of oldestPerson is Person!

As a result we can access its .name property.

Here's another example with 2 different types:

type Person = {name: string, age: number};
const people: Person[] = [
  { name: 'Amir', age: 10 }, 
  { name: 'Betty', age: 20 }, 
  { name: 'Cecile', age: 15 }
 ];

type Bridge = {name: string, length: number, age: number};
const bridges = [
{ name: 'London Bridge', length: 269, age: 48 },
{ name: 'Tower Bridge', length: 244, age: 125 },
{ name: 'Westminster Bridge', length: 250, age: 269 }
]

const oldestPerson = getOldest(people); // type Person
const oldestBridge = getOldest(bridges); // type Bridge

console.log(oldestPerson.name); // 'Betty' ✅
console.log(oldestBridge.length); // '250' ✅
Enter fullscreen mode Exit fullscreen mode

You can try this in TypeScript Playground

When generics are not needed

Even if your function takes objects conforming to the HasAge interface; as long as you don't mean to return the same type you don't need generics.

function isFirstOlder<T extends HasAge>(a: T, b: T) {
  return a.age > b.age;
}
Enter fullscreen mode Exit fullscreen mode

The function above doesn't need to be generic. We can simply write:

function isFirstOlder(a: HasAge, b: HasAge) {
  return a.age > b.age;
}
Enter fullscreen mode Exit fullscreen mode

Resources

Feedback?

I'd love to hear your thoughts. Do you have other use cases? examples?


Photo by Joshua Coleman on Unsplash

Top comments (6)

Collapse
 
stealthmusic profile image
Jan Wedel • Edited

Great write up, thanks! I’m recently doing more and more typescript (coming from Java) and it’s sometimes confusing to get things right. Although I would also use a type it’s pretty handy for tests to use objects as types as you’ve shown.

The one thing that bugs me the most about the TS type system is the type erasure at runtime. I’ve had some bugs where while debugging I had a string in a variable of type int...

Collapse
 
juliang profile image
Julian Garamendy

Hi Jan, Thank you for reading and commenting.

Having a string on a variable of type number is unfortunately possible because there's no TypeScript at runtime; only JavaScript.

If your TS configuration is strict this should not be normally possible, unless of course, you're loading and parsing external data at runtime, which is very common.

For instance, you expect an object's id to be of type number but the JSON response from the server has it as a string.

One way to avoid this is to validate the server response at runtime. You can do this using something like ts.data.json or io-ts

Here's an article on dev.to showing how to use ts.data.json

Collapse
 
stealthmusic profile image
Jan Wedel

In my case, it was an input element that was bound to the component in Angular. The types were correct, but the form returned strings...

Thread Thread
 
juliang profile image
Julian Garamendy

Ah. I'm afraid I don't have enough experience with Angular. I suppose there are other reasons for that miss-type to happen: a library could be exporting the wrong types.

Thread Thread
 
stealthmusic profile image
Jan Wedel

You can see it in the dom, that all form values are strings in the browser. There are no types. When you bin an integer to a form input, it will be a string eventually. When the user modifies it, the new string goes back to the model.

I really wish there were some statically typed version of TS that would be compiled to WebASM... maybe that would be a way to circumvent the JS quirks at runtime.

Collapse
 
jonlauridsen profile image
Jon Lauridsen

Nice example 👍