<pre><code class="language-text">Attention! This article has been edited with the help of AI. If that fact makes you twitch or you have a personal grudge against AI, if you’re worried it might bruise your fragile soul, if you’re dead sure Skynet started the same way, or if your backside is already overheating - just stop here. Go meditate, bake a pie, or yell at some clouds instead. Preserve your inner peace and channel that energy into something useful. Thanks!
</code></pre>
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.

Anatoly Nevzorov

Generics in TypeScript enable writing reusable, type-safe code by using placeholder types that adapt to different data types. They eliminate code duplication while maintaining type safety, allowing functions and components to work with multiple types without using 'any'. The guide covers basic syntax, constraints, multiple type parameters, and practical use cases like API responses and utility functions, while warning against overuse and complexity.

Generics in TypeScript: write once, work everywhere

Thank you for this great article on Generics 🔥💙

I’ve learned the basic of generics from this easy article.
Thanks for this smart and easy article.

This is very useful for a beginner like me.

This is really helpful, thanks man