You know that moment when you’re writing a function, and it hits you—“Wait, I need this same logic for strings, for users, for settings…”? And you start duplicating code like a photocopier on overdrive? Yeah. That’s the sound of tech debt knocking. Generics in TypeScript? They’re not some flashy gimmick. They’re the quiet fix. The “write once, work everywhere” backbone for smart, type-safe code. No hacks. No <code>any</code> loopholes. Just… clarity with flexibility.
Let’s cut through the noise.
<hr>
Imagine you’re building a vending machine. You want it to handle snacks, drinks, maybe even tiny plushies. You could build a separate machine for each. Or—genius move—you design one that adapts. Slot in a chip? Fine. A soda? Cool. A rubber duck? Why not. That’s generics. A template that doesn’t lock you into one type.
So, what’s the deal with <code>&lt;T&gt;</code>? That weird angle-bracket thing?
Think of <code>T</code> as a placeholder. A stand-in. Like “insert your type here.” It’s not a real type—yet. It’s a promise: “Hey, when you call me, tell me what you’re working with, and I’ll adjust.”
<pre><code class="language-ts">function wrapInBox&lt;T&gt;(item: T): { content: T } {
 return { content: item };
}
</code></pre>
See that <code>&lt;T&gt;</code>? It’s not syntax fluff. It’s the key. Now you can:
<pre><code class="language-ts">const stringBox = wrapInBox(&quot;hello&quot;); // { content: string }
const numBox = wrapInBox(42); // { content: number }
const chaosBox = wrapInBox({ wow: true }); // { content: { wow: boolean } }
</code></pre>
No duplication. No <code>any</code> chaos. Just clean, reusable logic. And TypeScript still knows exactly what’s inside. That’s the sweet spot.
<hr>
But wait—what if your <code>T</code> needs rules? Like, what if you’re sorting stuff, and it must have a <code>name</code>?
Enter constraints. You can limit what <code>T</code> can be.
<pre><code class="language-ts">interface Named {
 name: string;
}

function getNames&lt;T extends Named&gt;(items: T[]): string[] {
 return items.map(item =&gt; item.name);
}
</code></pre>
Now, if someone tries to pass in an array of numbers? TypeScript goes: “Nah, pal. These don’t have names.” And it yells at compile time. No runtime surprises. No “undefined is not a function” at 2 a.m.
<hr>
Here’s where it gets spicy.
You can go full generic gymnastics. Multiple type params? Sure.
<pre><code class="language-ts">function pairUp&lt;A, B&gt;(first: A, second: B): [A, B] {
 return [first, second];
}

pairUp(&quot;hi&quot;, 100); // [string, number]
</code></pre>
Or even default types—like function defaults, but for types:
<pre><code class="language-ts">function createArray&lt;T = string&gt;(item: T, count: number): T[] {
 return Array(count).fill(item);
}

createArray(5, 3); // number[]
createArray(undefined); // string[] — because default kicks in
</code></pre>
<hr>
Now, the downsides. Because nothing’s perfect.
Generics? They add cognitive load. For a junior dev, <code>&lt;T extends U where V&gt;</code> can look like hieroglyphs. It’s powerful—but power comes with complexity. Overuse? You end up with type soup. <code>Wrapper&lt;Promise&lt;Ref&lt;T[]&gt;&gt;&gt;</code>—what even is that? It’s like naming your kid “Sir Charles III, Esq.”
And debugging? Sometimes the error messages are… creative. “Type ‘X’ is not assignable to type ‘infer Y in conditional over mapped tuple’.” Cool. Thanks.
Also—let’s be real—not every function needs generics. If you’re only ever dealing with strings, just use <code>string</code>. Don’t flex with <code>&lt;T&gt;</code> where it’s not needed. YAGNI. You ain’t gonna need it.
<hr>
So, when do you use them?
<ul>
<li>Reusable utilities: <code>map</code>, <code>filter</code>, <code>cache</code>, <code>result wrappers</code>—anything that shouldn’t care about the data shape.</li>
<li>API clients: When you fetch data and want to keep type safety across different endpoints.</li>
<li>Component libraries: React props, forms, modals—pass types down like heirlooms.</li>
</ul>
When not?
<ul>
<li>When the type is fixed. No point over-engineering.</li>
<li>When the team’s still learning TypeScript. Start simple.</li>
<li>When the generic adds zero value. If it’s only used with one type—just… don’t.</li>
</ul>
<hr>
Here’s a real-world moment.
You’re building a todo app. You have <code>fetchTodos()</code>, <code>fetchUsers()</code>, <code>fetchPosts()</code>. All follow the same pattern: <code>loading</code>, <code>data</code>, <code>error</code>.
Instead of writing three nearly identical structures?
<pre><code class="language-ts">type ApiResponse&lt;T&gt; = {
 data: T | null;
 loading: boolean;
 error: string | null;
};

const todoResponse: ApiResponse&lt;Todo[]&gt; = { data: [...], loading: false, error: null };
const userResponse: ApiResponse&lt;User&gt; = { data: { name: &quot;Alex&quot; }, loading: true, error: null };
</code></pre>
Boom. One type. Infinite uses. Type safety intact. No copy-paste zombies haunting your codebase.
<hr>
Bottom line?
Generics aren’t magic dust you sprinkle on everything. But when you need consistency across varying types—say, a function that handles user data, config objects, or API responses without turning into a typeless mess—they’re more like a master key. One key. Many doors. Each lock is different, but the mechanism? Same. You don’t rebuild the door; you design the key to adapt. That’s the power. Use it where flexibility and safety must coexist. Not everywhere. Not always. But exactly when it clicks. And when it does? Feels less like coding, more like choreographing something that just… flows.

The official daily.dev web development community. Led by thought leaders and webdev experts. Join the Squad!

WebDev

TypeScript generics enable writing reusable, type-safe code by using placeholder types that adapt to different data types without sacrificing type checking. The article explains how generics work with practical examples, covers constraints for limiting generic types, discusses when to use them (utilities, API clients, component libraries) versus when to avoid them (fixed types, over-engineering), and demonstrates real-world applications like building consistent API response structures.

Generics in TypeScript: write once, work everywhere