Forem: Manuj Sankrit

Page Numbers Lie: Offset vs Cursor Pagination

Manuj Sankrit — Sun, 05 Apr 2026 07:54:04 +0000

From Interview Notes To Production Reality

While I was preparing for interviews, I came across a high-level system design for a News Feed — specifically from the frontend perspective. That's where I first encountered the terms offset-based and cursor-based pagination.

I read about them. Briefly. You know how interview prep goes — there's always more ground to cover than time allows, so you skim what you can, bookmark the rest, and silently promise yourself you'll come back to it. Spoiler: you don't. 😅

Fast forward to recently — a requirement came up at work to implement infinite scroll with virtualization. And just like that, pagination was back on my desk, except this time it wasn't optional reading. It was a production decision.

So I finally sat down, went deep, and now here we are. This post is everything that clicked for me.

We'll cover:

Why offset-based pagination is "dumb" in a specific, technical way
What cursor-based pagination actually does differently
How Relay formalised cursors into a standard
How to choose between them without overthinking it

First — What Even Is Pagination?

Before we compare them, let's align on the problem.

When an API has thousands of records, returning all of them at once is a bad idea — too much data, too slow, too memory-hungry. Instead, we return results in chunks. Pagination is the mechanism that controls which chunk the client gets.

The two dominant approaches for this are offset-based and cursor-based. They sound similar. They are not.

Offset-Based Pagination

The Idea

The client tells the server: "Skip the first N items and give me the next M."

query GetPosts {
  posts(offset: 40, limit: 20) {
    id
    title
    author
  }
}

On the server this translates to pure array math:

const getPosts = (offset: number, limit: number) => {
  return ALL_POSTS.slice(offset, offset + limit);
};

// offset: 40, limit: 20
// → returns ALL_POSTS[40] through ALL_POSTS[59]

Simple. Predictable. Easy to reason about.

The client tracks offset and increments it by limit on each fetch:

const fetchNextPage = () => {
  const nextOffset = currentItems.length;
  fetchMore({ variables: { offset: nextOffset, limit: 20 } });
};

And if you want to know when to stop? The server returns a total:

type PostsResult {
  posts: [Post!]!
  total: Int! # total count across ALL pages — not just this one
}

// Client knows it's done when:
const hasNextPage = currentItems.length < total;

The Skipped Item Problem

Here's where offset starts to crack. Imagine a list of 10 products:

Page 1 → items [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]  (offset: 0, limit: 10)

While you're looking at Page 1, item #5 gets deleted. The list shifts:

After deletion → [1, 2, 3, 4, 6, 7, 8, 9, 10, 11]

When you request Page 2 (offset: 10):

Server skips first 10 → starts from item #12
Item #11 was never shown to you. It "slipped through" the gap.

⚠️ The list shrinks → you miss items.

The Duplicate Item Problem

This one is more common and more noticeable. A newsfeed where new posts appear at the top:

Page 1 → [post10, post9, post8, post7, post6, post5, post4, post3, post2, post1]

While you're reading, someone publishes a new post. It becomes post11 at position #1:

Updated list → [post11, post10, post9, post8, post7, post6, post5, post4, post3, post2, ...]

When you request Page 2 (offset: 10):

Server skips 10 → starts from index 10
Index 10 is now post1 — which you already saw at the bottom of Page 1

⚠️ The list grows → you see items twice.

Why This Happens

Offset is "positional" — it says "skip N positions", not "skip N specific items." When the list changes shape, positions shift but the offset doesn't know or care.

// Offset doesn't know what you've seen.
// It only knows how many slots to skip.
// That distinction is exactly the problem.

When Offset Is Still The Right Choice

Despite these drawbacks, offset is perfectly fine when:

Data rarely mutates — a list of dealers, product catalogue, search results. Nobody is inserting new dealers between your pages.
You need "jump to page N" — offset = (page - 1) * limit is trivial math. Cursors can't do this.
Simpler implementation is preferred — no cursor encoding, no special cache policies, just slice an array.

For our production app use-case? this was the goto approach since data don't change while a user is scrolling.

Cursor-Based Pagination

The Idea

Instead of saying "skip 40 items", the client says "give me items that come after this specific item."

The server returns a cursor alongside each result — a pointer to that item's position. The client sends the cursor back on the next request.

query GetPosts($after: String, $limit: Int) {
  posts(after: $after, limit: $limit) {
    items {
      id
      title
    }
    pageInfo {
      endCursor # cursor pointing to the last item returned
      hasNextPage # whether more items exist after this
    }
  }
}

First request — no cursor:

// Fetch first 20
fetchPosts({ variables: { limit: 20 } })

// Server returns:
{
  items: [...20 posts],
  pageInfo: {
    endCursor: "YTI5Mjg3NDU=",  // cursor for the last item
    hasNextPage: true
  }
}

Next request — pass the cursor back:

// Fetch next 20 starting after the last seen item
fetchPosts({ variables: { after: 'YTI5Mjg3NDU=', limit: 20 } });

The server doesn't skip N positions — it finds the item the cursor points to and returns everything after it:

const getPosts = (after: string | null, limit: number) => {
  if (!after) {
    return ALL_POSTS.slice(0, limit);
  }

  const decodedCursor = decodeCursor(after); // e.g. a timestamp or ID
  const startIndex = ALL_POSTS.findIndex(
    (post) => post.createdAt < decodedCursor,
  );

  return ALL_POSTS.slice(startIndex, startIndex + limit);
};

Why Cursors Fix The Offset Problems

Going back to our newsfeed example:

You last saw: post1 (cursor: "abc123" → points to post1's timestamp)

New post11 gets added at the top.

Next request: "give me posts after post1"
Server finds post1 by its timestamp → returns post2 onward

It doesn't matter that the list grew. The cursor points to a specific item, not a position. The starting point is anchored to data, not an index.

⚠️ The cursor says "after this specific item" — not "after position N."
The list can grow or shrink all it wants. The bookmark holds.

Same story for deletions. If the item the cursor pointed to gets deleted:

// Timestamp-based cursor is resilient:
SELECT * FROM posts WHERE created_at < $cursorTimestamp ORDER BY created_at LIMIT $limit
// "Give me posts created before this moment in time"
// Even if that exact post is gone, the timestamp still works

This is why cursors are typically timestamps or encoded IDs rather than raw row IDs — a timestamp survives deletions, a row ID might not.

What Is An Opaque Cursor?

Notice the cursor we returned earlier: "YTI5Mjg3NDU=" — that's not a meaningful string. It's a base64 encoded value.

// Encoding a cursor (server side)
const encodeCursor = (value: string): string =>
  Buffer.from(value).toString('base64');

// Decoding a cursor (server side)
const decodeCursor = (cursor: string): string =>
  Buffer.from(cursor, 'base64').toString('utf-8');

// "2024-01-15T10:30:00Z" → "MjAyNC0wMS0xNVQxMDozMDowMFo="

Why hide it? Three reasons:

Abstraction — the client doesn't need to know or care how the cursor works internally. It's a black box to pass back.
Security — if users can see cursor = 12345, they might try to manually construct cursors. Encoding prevents this.
Flexibility — the server can change cursor internals (switch from ID to timestamp) without breaking any client that treats it as opaque.

type PageInfo = {
  endCursor: string | null; // opaque — client never decodes this
  hasNextPage: boolean;
};

The Trade-Off You Give Up

Cursors buy you stability but cost you one thing — you cannot jump to arbitrary pages.

// Offset — trivial
const jumpToPage = (page: number, limit: number) => ({
  offset: (page - 1) * limit,
});

// Cursor — impossible without fetching every preceding page first
// "Page 5" has no meaning — you'd need page 1's cursor, then page 2's, etc.

If your UI has a "jump to page 10" button, offset is your only option. Cursor pagination is strictly sequential — forward only.

Relay: The Standard That Formalised Cursors

When Facebook open-sourced GraphQL, they also introduced Relay — a client-side framework with its own pagination spec. Most GraphQL ecosystems reference it today even without using Relay itself.

Relay formalised cursor pagination into a consistent shape using three concepts:

Connection → the whole paginated list
Edge       → a single item + its cursor bundled together
Node       → the actual data item inside the Edge

In GraphQL schema form:

type PostConnection {
  edges: [PostEdge!]!
  pageInfo: PageInfo!
}

type PostEdge {
  node: Post! # the actual item
  cursor: String! # that item's position bookmark
}

type PageInfo {
  endCursor: String
  hasNextPage: Boolean!
  startCursor: String
  hasPreviousPage: Boolean!
}

The query looks like:

query {
  posts(first: 10, after: "opaqueCursor") {
    edges {
      cursor # each item gets its OWN cursor
      node {
        id
        title
      }
    }
    pageInfo {
      endCursor
      hasNextPage
    }
  }
}

The key Relay innovation — every item gets its own cursor, not just the last one. This lets you start pagination from any arbitrary item in the list, not just the end.

Apollo Client has built-in support for this via relayStylePagination():

const client = new ApolloClient({
  cache: new InMemoryCache({
    typePolicies: {
      Query: {
        fields: {
          posts: relayStylePagination(), // handles merge automatically
        },
      },
    },
  }),
});

For offset-based pagination you handle the cache merge manually — which is a separate topic worth its own post.

Side By Side

	Offset	Cursor
Query args	`offset, limit`	`after, limit`
Server logic	`array.slice(offset, offset + limit)`	find cursor → return next N
Stable under inserts	❌ Duplicates	✅ Stable
Stable under deletes	❌ Skips items	✅ Stable
Jump to page N	✅ Easy	❌ Not possible
Implementation	Simple	More complex
Apollo cache	Manual `merge`	`relayStylePagination()`
Best for	Static / rarely mutating data	Live / frequently mutating data

How To Choose

One question settles it:

Does new data appear at the top of the list while users are actively scrolling through it?

Yes → Cursors. Twitter feed, notifications, chat messages. New items push everything down and offset will show duplicates.
No → Offset is fine. Dealer locator, product catalogue, search results. The data is stable between requests. Offset's instability never materialises.

The mistake I see most often is reaching for cursor complexity when offset was completely adequate. A recipe list that hasn't changed in six months doesn't need cursor pagination. A live activity feed absolutely does.

Wrapping Up

Page numbers aren't broken — they're just making an assumption: "the list isn't changing while you're looking at it." When that assumption holds, they work perfectly. When it doesn't, you get ghosts and missing items.

Cursors drop that assumption entirely. They don't care what the list looked like before your request — they only care about "what comes after this specific item."

Understanding this distinction doesn't just help you pick the right pagination strategy. It changes how you think about stateful data fetching in general — which, as it turns out, is one of the more interesting problems in frontend engineering.

Pranipat 🙏!

Which promise method do you need?

Manuj Sankrit — Sun, 01 Mar 2026 09:38:41 +0000

Last week, a flatmate of mine — a seasoned Java/Spring backend developer — knocked on my door with a quick frontend question. He'd been handed a small task on the frontend side of his project, nothing major, and had reached out for a sanity check before pushing his code.

He had used Promise.race to implement a fallback — if the primary API failed, he wanted to use the backup. The logic made sense in his head. But the implementation was wrong, and the bug was subtle enough that it had slipped through his initial testing.

When I asked him "do you know the difference between race and any?", he paused. And honestly? The pause made me think. Because two years ago, I would have paused too.

That conversation sent me down a rabbit hole — rebuilding polyfills for all four Promise methods — all, any, race, and allSettled — from scratch, just to make sure I truly understood the internals and not just the surface-level API.

Now, there are already separate blog posts floating around on each of these (including some I wrote a couple of years ago 😄). But the real gap isn't understanding each method individually — it's knowing how they relate to each other and which one to reach for in a given situation.

So this is that blog where I wanted to share my learning. The consolidated one. The "one ring to rule them all" of Promise methods. 💍

The Quick Cheat Sheet (For the Impatient 😄)

Method	Resolves when	Rejects when	Returns
`Promise.all`	All resolve	Any one rejects	Array of values (ordered)
`Promise.any`	Any one resolves	All reject	First resolved value
`Promise.race`	Any one settles	Any one rejects first	First settled value
`Promise.allSettled`	All settle (always resolves)	Never	Array of `{status, value/reason}`

The Decision Framework

Before the deep dive, here's the mental model I use when picking between these four:

Do you need ALL to succeed? → Promise.all

Do you need just ONE to succeed, ignoring the rest? → Promise.any

Do you want whoever finishes first — win or lose? → Promise.race

Do you want the full picture regardless of success or failure? → Promise.allSettled

If that's all you needed, you're welcome. 😄 For everyone else, let's go deeper.

Promise.all

What it does

Takes an array of promises and returns a single promise that resolves with an array of all resolved values, in the same order as the input. If any one promise rejects, the whole thing rejects immediately — it doesn't wait for the rest.

const promise1 = Promise.resolve('Hello');
const promise2 = Promise.resolve(42);
const promise3 = new Promise((resolve) => setTimeout(resolve, 100, 'World'));

Promise.all([promise1, promise2, promise3])
  .then((values) => console.log(values))
  .catch((error) => console.error(error));
// Output: ["Hello", 42, "World"]

When to use it

Fetching data from multiple APIs where all results are required to render (think dashboards)
Uploading multiple files and waiting for all to complete before showing a success message
Batch database operations where all must succeed together

Polyfill

function all(promises) {
  function executorFunction(resolve, reject) {
    const result = [];
    let pendingCount = promises.length;

    if (pendingCount === 0) {
      resolve(result);
      return;
    }

    promises.forEach((promise, index) => {
      Promise.resolve(promise).then((value) => {
        result[index] = value; // 👈 index assignment, not push
        if (--pendingCount === 0) {
          resolve(result);
        }
      }, reject); // first rejection short-circuits everything
    });
  }
  return new Promise(executorFunction);
}

⚠️ The gotcha hiding in plain sight: Notice I use result[index] = value and NOT result.push(value). If I used push, the order would depend on which promise resolved first — not the original input order. Promise.all guarantees output order matches input order, and this one line is why. The pendingCount counter is how I know when every promise has settled without needing await.

Promise.any

What it does

Returns a promise that resolves with the first fulfilled value. Rejections are silently ignored — unless all promises reject, in which case it throws an AggregateError wrapping all the rejection reasons.

const promise1 = Promise.reject(new Error('First failed'));
const promise2 = new Promise((resolve) => setTimeout(resolve, 100, 'Success'));
const promise3 = Promise.reject(new Error('Second failed'));

Promise.any([promise1, promise2, promise3])
  .then((value) => console.log(value))
  .catch((error) => console.error(error));
// Output: "Success"

When to use it

Trying multiple CDN sources and using whichever responds first
Primary + backup service pattern — use the backup only if primary fails
Optimistic UI — show cached data or fresh API data, whoever arrives first wins

Polyfill

function any(promises) {
  function executorFunction(resolve, reject) {
    const errors = [];
    let pendingCount = promises.length;
    if (pendingCount === 0) {
      reject(new AggregateError(errors, 'No promises were passed'));
      return;
    }

    promises.forEach((promise, idx) => {
      Promise.resolve(promise)
        .then((val) => resolve(val)) // first resolve wins
        .catch((err) => {
          errors[idx] = err; // preserve order of errors
          if (--pendingCount === 0) {
            reject(new AggregateError(errors, 'All promises were rejected'));
          }
        });
    });
  }
  return new Promise(executorFunction);
}

⚠️ Two gotchas here:

Gotcha 1 — AggregateError is not a regular Error: When all promises reject, the catch block receives an AggregateError. Don't try to read error.message expecting individual reasons — access error.errors (the array) to get each rejection reason.

Gotcha 2 — Empty array behavior: Promise.any([]) immediately rejects with AggregateError. This is the opposite of Promise.all([]), which immediately resolves with an empty array. Catch this during interviews — it's a classic trap. 😄

Notice the symmetry with the Promise.all polyfill — but inverted. In all, a single rejection short-circuits. In any, a single resolution short-circuits. We still use indexed assignment for errors (not push) so the error order matches the input order, which matters when you're debugging why everything blew up.

Promise.race

What it does

Returns a promise that settles as soon as the first promise settles — resolve or reject. Whoever finishes first, wins. The others are abandoned.

const promise1 = new Promise((resolve) => setTimeout(resolve, 200, 'Slow'));
const promise2 = new Promise((resolve) => setTimeout(resolve, 100, 'Fast'));

Promise.race([promise1, promise2])
  .then((value) => console.log(value))
  .catch((error) => console.error(error));
// Output: "Fast"

When to use it

The classic use case — implementing a timeout for any async operation:

const fetchData = () => fetch('https://api.example.com/data');

const timeout = (ms) =>
  new Promise((_, reject) =>
    setTimeout(() => reject(new Error('Request timed out')), ms),
  );

Promise.race([fetchData(), timeout(5000)])
  .then((response) => response.json())
  .catch((error) => console.error(error));
// Rejects with "Request timed out" if API doesn't respond in 5 seconds

Polyfill

function race(promises) {
  function executorFunction(resolve, reject) {
    for (const promise of promises) {
      Promise.resolve(promise).then(resolve, reject);
    }
  }
  return new Promise(executorFunction);
}

This is the simplest polyfill of the four — and the elegance is worth appreciating. Once a Promise settles, subsequent calls to resolve or reject are silently ignored by the JS engine. So we just attach handlers to every promise and let the first one win naturally. No counter, no result array, no complexity.

⚠️ The race vs any confusion: This is the most common mixup I see.

race = first to finish (resolve OR reject). A rejection wins the race too.

any = first to succeed. Rejections are ignored until all fail.

If the first promise to settle in Promise.race is a rejection, the whole thing rejects — it doesn't wait for a successful one. If that's not what you want, you probably want Promise.any.

⚠️ Empty array is a silent trap: Promise.race([]) returns a promise that is permanently pending — it never settles. Unlike Promise.all([]) which resolves immediately, or Promise.any([]) which rejects immediately, race just waits forever. Always guard against this in production code:
if (promises.length === 0)
  return Promise.reject(new Error('No promises provided'));

Promise.allSettled

What it does

Waits for all promises to settle and returns an array of objects describing each outcome. It never rejects — you always get the full picture, wins and losses both.

const promise1 = Promise.resolve('Hello');
const promise2 = Promise.reject(new Error('Something went wrong'));
const promise3 = new Promise((resolve) => setTimeout(resolve, 100, 'World'));

Promise.allSettled([promise1, promise2, promise3]).then((results) =>
  console.log(results),
);
// Output:
// [
//   { status: "fulfilled", value: "Hello" },
//   { status: "rejected", reason: Error: Something went wrong },
//   { status: "fulfilled", value: "World" }
// ]

When to use it

Fetching from multiple APIs where partial success is acceptable — show what you have, log what failed
Batch processing where some failures are expected and shouldn't stop the rest
Running multiple independent operations and reporting the full outcome

Polyfill

function allSettled(promises) {
  function executorFunction(resolve) {
    // ☝️ no reject parameter — we always resolve
    const result = [];
    let pendingCount = promises.length;

    if (pendingCount === 0) {
      resolve(result);
      return;
    }

    promises.forEach((promise, idx) => {
      Promise.resolve(promise)
        .then((value) => (result[idx] = { status: 'fulfilled', value }))
        .catch((reason) => (result[idx] = { status: 'rejected', reason }))
        .finally(() => {
          if (--pendingCount === 0) {
            resolve(result);
          }
        });
    });
  }
  return new Promise(executorFunction);
}

⚠️ Implementation insight: The executor function deliberately omits the reject parameter — this promise should never reject, so why even have it there? The .finally() is the cleanest way to decrement the counter regardless of whether .then or .catch ran. Both write to result[idx] before .finally fires, so by the time we call resolve, every slot is already filled.

The Side-by-Side That Makes It Click

Let me pass the same promises to all four and you'll immediately see the difference:

const fast = Promise.resolve('fast');
const slow = new Promise((res) => setTimeout(res, 200, 'slow'));
const fail = Promise.reject(new Error('failed'));

// Promise.all — one failure, everything fails
Promise.all([fast, slow, fail]);
// ❌ Rejects with Error: "failed"

// Promise.any — one success is enough
Promise.any([fast, slow, fail]);
// ✅ Resolves with "fast"

// Promise.race — fail settles first (it's already rejected)
Promise.race([fail, fast, slow]);
// ❌ Rejects with Error: "failed"

// Promise.allSettled — never rejects, full picture
Promise.allSettled([fast, slow, fail]);
// ✅ Resolves with:
// [
//   { status: 'fulfilled', value: 'fast' },
//   { status: 'fulfilled', value: 'slow' },
//   { status: 'rejected', reason: Error: 'failed' }
// ]

Common Mistakes (That I've Also Made 😅)

1. Reaching for Promise.all when partial failure is fine

If your dashboard can render with 3 out of 4 APIs responding, use allSettled and handle failures individually. Promise.all will discard all results the moment one fails. Most real-world scenarios are more forgiving than Promise.all assumes.

2. Confusing race and any

race = first to finish. any = first to succeed. If you want a timeout that only triggers when your request actually fails (not just when it's slower than a competing promise), you want any not race.

3. Forgetting AggregateError in Promise.any

Your catch block for Promise.any will receive an AggregateError when all promises reject. Accessing error.message won't give you the individual reasons. You need error.errors — the array of all rejection reasons.

4. Using push instead of index assignment in custom implementations

If you ever write a custom aggregator and use result.push(value) instead of result[index] = value, you'll silently break the order guarantee. The output order will depend on resolution speed, not input order. And this will only show up in production under load. Fun times. 😄

Quick Reference

Method	Use when...
`Promise.all`	You need ALL results and one failure should abort everything
`Promise.any`	You need ONE success and don't care which one
`Promise.race`	You want the first to settle — success or failure
`Promise.allSettled`	You want all outcomes and will handle each individually

Building these polyfills from scratch was genuinely one of the better learning exercises I've done recently. Reading docs tells you what these methods do. Writing the internals tells you why they behave the way they do — and that's where the real understanding lives.

Until next time, Pranipat 🙏!

Handy Bit Manipulation Tricks

Manuj Sankrit — Fri, 13 Feb 2026 06:54:48 +0000

I was digging through React's source code and stumbled upon some bitmask logic for handling component states. At first glance, it looked cryptic—just a bunch of &, |, and << operators. But once I understood what was happening, it clicked. These operations are ridiculously fast and efficient.

Here are some tricks I find myself reaching for when performance actually matters.

Basic Bit Operations

Setting a Bit

To set the bit at position pos, use the bitwise OR operator. Think of (1 << pos) as a laser pointer—you're pointing it exactly at one spot, and | is the "turn on" switch:

function setBit(n: number, pos: number): number {
  return n | (1 << pos);
}

Example: Setting bit at position 2 in 0b1010 gives us 0b1110

   0b1010
 | 0b0100  (laser pointer at position 2)
-----------
   0b1110

Clearing a Bit

To clear a bit at position pos, we AND with the inverted mask:

function clearBit(n: number, pos: number): number {
  return n & ~(1 << pos);
}

Example: Clearing bit at position 1 in 0b1110 gives 0b1100

   0b1110
 & 0b1101
-----------
   0b1100

Toggling a Bit

Toggling is straightforward with XOR:

function toggleBit(n: number, pos: number): number {
  return n ^ (1 << pos);
}

Example: Toggling bit at position 2 in 0b1010 → 0b1110

   0b1010
 ^ 0b0100
-----------
   0b1110

Checking a Bit

To check if a bit is set:

function checkBit(n: number, pos: number): boolean {
  return ((n >> pos) & 1) !== 0;
}

Example: Checking bit at position 1 in 0b0110

   0b0110
 >>     1
-----------
   0b0011
 & 0b0001
-----------
   0b0001 (true)

⚠️ JS/TS Gotcha: Bitwise operators in JavaScript convert numbers into 32-bit signed integers. If you're working with large numbers (above 2³¹-1), like database IDs or timestamps, this magic will turn into a nightmare. For those cases, stick with BigInt or regular arithmetic.

Some Clever Tricks

Check if a Number is a Power of 2

This one's pretty neat:

function isPowerOfTwo(n: number): boolean {
  return n > 0 && (n & (n - 1)) === 0;
}

The trick here is that powers of 2 have exactly one bit set(means one bit is 1). When you subtract 1, all the bits after that flip, so the AND operation gives you 0.

n = 8 (0b1000)
n - 1 = 7 (0b0111)
n & (n - 1) = 0b0000

Count Set Bits (Brian Kernighan's Algorithm)

function countSetBits(n: number): number {
  let count = 0;
  while (n) {
    n = n & (n - 1);
    count++;
  }
  return count;
}

This keeps clearing the rightmost set bit until nothing's left. Each iteration bumps the count.

0b1011 → 0b1010 → 0b1000 → 0b0000
count: 1      2        3

Find the Rightmost Set Bit

function rightmostSetBit(n: number): number {
  return n & -n;
}

This works because -n (two's complement) flips all the bits and adds 1, which isolates just the rightmost set bit.

n = 0b1010
-n = 0b0110
n & -n = 0b0010

Swap Two Numbers Without a Temp Variable

function swap(a: number, b: number): [number, number] {
  a = a ^ b;
  b = a ^ b;
  a = a ^ b;
  return [a, b];
}

XOR has this cool property where a ^ a = 0 and a ^ 0 = a, so you can swap without needing extra space.

Check if a Number is Even

function isEven(n: number): boolean {
  return (n & 1) === 0;
}

Way faster than the modulo operator. The least significant bit is 0 for even numbers.

The Trade-off: Efficiency vs Readability

Now, here's the thing. Every concept has its pros and cons, and bit manipulation is no exception. Sure, these operations are super efficient and lean, but they definitely compromise the KISS principle.

If you go overboard with bit tricks in your codebase, you're gonna have a problem. Junior developers—well, the ones that haven't been replaced by AI yet 😁—might struggle to understand what's going on. Heck, even you might come back to your own code six months later and wonder what you were thinking.

So use bit manipulation wisely:

Performance-critical sections: Where every cycle counts
Well-documented code: Add comments explaining the bit magic
Specific algorithms: Like the ones mentioned above
Standard patterns: Stick to common tricks that developers recognize

But for everyday logic? Just write clear, readable code. n % 2 === 0 is perfectly fine for checking even numbers in most cases. Don't sacrifice code clarity just to show off your bit manipulation skills.

Where This Actually Matters

You'll see bit manipulation used in:

Permissions systems: Like Unix file permissions (chmod 755)
Feature flags: When you need to pack multiple boolean flags into a single integer
Subset generation: Iterating through all possible combinations
Performance-critical code: These operations literally execute in one CPU cycle

Quick Reference

Operation	Code	Example
Set bit	`n \| (1 << pos)`	`0b1010 \| (1 << 2)` → `0b1110`
Clear bit	`n & ~(1 << pos)`	`0b1110 & ~(1 << 1)` → `0b1100`
Toggle bit	`n ^ (1 << pos)`	`0b1010 ^ (1 << 2)` → `0b1110`
Check bit	`(n >> pos) & 1`	`(0b1010 >> 1) & 1` → `1` (set)
Power of 2	`n & (n - 1) === 0`	`8 & 7 === 0` → `true`
Even/Odd	`n & 1 === 0`	`4 & 1 === 0` → `true` (even)
Rightmost set	`n & -n`	`0b1010 & -0b1010` → `0b0010`

These patterns might look weird at first, but after using them a few times, they start to make sense. Just remember: with great power comes great responsibility. Use them where they make sense, not everywhere.

Pranipat 🙏!

Mastering TypeScript Utility Types: Part 3 — Building Custom Utilities

Manuj Sankrit — Sun, 01 Feb 2026 17:02:20 +0000

In Part 1, we covered the "Sculptors"—Record, NonNullable, Pick, and Omit.

In Part 2, we unlocked the "Transformers & Type Thieves"—Partial, Exclude, ReturnType, and Parameters.

But here's what I learned the hard way: TypeScript's built-in utilities only go one level deep.

Tried using Partial<T> on a deeply nested config object? It only makes the top-level properties optional. The nested ones? Still required. Same deal with Readonly<T>.

So we're building our own.

Today's journey:

Build DeepPartial<T> from scratch (recursive optional everything)
Build DeepReadonly<T> from scratch (recursive immutability)
Understand infer (TypeScript's capture keyword)
Template Literal Types (type-safe string patterns)
The Polymorphic pattern (how component libraries like Radix UI work)

The Problem: Built-ins Don't Go Deep Enough

Here's a scenario I ran into recently:

// Complex config object (pretty common in large apps)
type AppConfig = {
  analytics: {
    enabled: boolean;
    trackingId: string | null;
  };
  api: {
    baseUrl: string;
    timeout: number;
    retries: {
      enabled: boolean;
      maxAttempts: number;
    };
  };
};

// For tests, we want to override specific nested values
// Try using Partial<T>:
type TestConfig = Partial<AppConfig>;

const testConfig: TestConfig = {
  api: {
    baseUrl: 'http://localhost:3000',
    // ❌ Error: Property 'timeout' is missing!
    // ❌ Error: Property 'retries' is missing!
  },
};

The problem: Partial<AppConfig> only makes analytics? and api? optional. Once we start defining api, TypeScript still expects us to provide all its properties which is not helpful.

Building `DeepPartial<T>` - The Journey

Let me walk through how I figured this out.

Step 1: Starting Point

We know Partial<T> works like this:

type Partial<T> = {
  [P in keyof T]?: T[P];
};

Translation: "For every property P in type T, make it optional (?), keep its type as T[P]."

Step 2: What If We Just... Recurse?

My first attempt:

type DeepPartial<T> = {
  [P in keyof T]?: DeepPartial<T[P]>;
  //                 ^^^^^^^^^^^ Recursively apply to nested objects
};

Seemed logical. Apply DeepPartial to the value too.

Problem: This breaks spectacularly for primitives. What does DeepPartial<string> even mean? TypeScript freaks out.

Step 3: The Fix - Conditional Check

Ah. We need to ask: "Is this thing an object? If yes, recurse. If no, leave it alone."

export type DeepPartial<T> = T extends object
  ? {
      [P in keyof T]?: DeepPartial<T[P]>;
    }
  : T;

Breaking it down:

T extends object - Check if T is an object type
? { ... } - If YES, create mapped type with optional recursive properties
: T - If NO (primitive like string or number), keep as-is

Now it works:

type AppConfig = {
  analytics: {
    enabled: boolean;
    trackingId: string | null;
  };
  api: {
    baseUrl: string;
    timeout: number;
  };
};

type TestConfig = DeepPartial<AppConfig>;

const testConfig: TestConfig = {
  api: {
    baseUrl: 'http://localhost:3000',
    // ✅ timeout is now optional!
  },
  // ✅ analytics is optional too!
};

Real-World Usage

Here's where this actually saved me:

1. Test fixtures:

// Full app translations structure
type Translations = {
  common: {
    buttons: {
      submit: string;
      cancel: string;
    };
    errors: {
      required: string;
      invalid: string;
    };
  };
  pages: {
    home: {
      title: string;
      subtitle: string;
    };
  };
};

// Locale-specific overrides - only define what's different
const frenchTranslations: DeepPartial<Translations> = {
  common: {
    buttons: {
      submit: 'Soumettre',
      // ✅ Don't need to define 'cancel'
    },
  },
  // ✅ Don't need to define 'pages' at all
};

2. Feature flag overrides:

type FeatureFlags = {
  checkout: {
    expressPayment: boolean;
    guestCheckout: boolean;
  };
  search: {
    autocomplete: boolean;
    filters: {
      price: boolean;
      brand: boolean;
    };
  };
};

// Override just what we need for this environment
const stagingFlags: DeepPartial<FeatureFlags> = {
  checkout: {
    expressPayment: true,
    // ✅ guestCheckout keeps default
  },
};

Why this is powerful: We can override any nested property without rebuilding the entire structure. Perfect for:

Test fixtures
Locale translations
Environment-specific configs
Theme customization

Building `DeepReadonly<T>` - Going Immutable

Next challenge: deep immutability.

The Problem I Ran Into

const config = {
  api: {
    endpoints: {
      users: '/api/users',
      products: '/api/products',
    },
  },
} as const;

// Surprise! 'as const' only goes one level deep
config.api.endpoints.users = '/hacked'; // ❌ This actually works! Bug waiting to happen

Not what I expected.

Step 1: The Obvious Attempt

Start with Readonly<T>:

type Readonly<T> = {
  readonly [P in keyof T]: T[P];
};

Translation: "For every property P in T, make it readonly."

Step 2: Add Recursion + A Critical Catch

Here's the thing I learned: Functions are objects in JavaScript. If we blindly recurse into functions, we break them. Can't have a readonly function.

export type DeepReadonly<T> = T extends Function
  ? T // Stop! Leave functions alone
  : T extends object
    ? {
        readonly [P in keyof T]: DeepReadonly<T[P]>;
      }
    : T;

The logic:

T extends Function - Is this a function? If YES → Don't touch it
T extends object - Is this an object? If YES → Apply readonly recursively
: T - Otherwise (primitive) → Keep as-is

Now it actually works:

type AppConfig = {
  api: {
    endpoints: {
      users: string;
      products: string;
    };
  };
  logger: (message: string) => void;
};

type ReadonlyConfig = DeepReadonly<AppConfig>;

const config: ReadonlyConfig = {
  api: {
    endpoints: {
      users: '/api/users',
      products: '/api/products',
    },
  },
  logger: (msg) => console.log(msg),
};

config.api.endpoints.users = '/hacked'; // ❌ Error: Cannot assign to 'users' - it's read-only
config.logger('test'); // ✅ Functions still work!

Where I Actually Use This

1. Configuration constants:

type AppSettings = {
  features: {
    darkMode: boolean;
    notifications: boolean;
  };
  limits: {
    maxFileSize: number;
    maxUploads: number;
  };
};

// Make entire config immutable
export const settings: DeepReadonly<AppSettings> = {
  features: {
    darkMode: true,
    notifications: false,
  },
  limits: {
    maxFileSize: 5242880, // 5MB
    maxUploads: 10,
  },
};

// Anywhere in the app
settings.limits.maxFileSize = 999; // ❌ Error - protected from accidental changes

2. Redux/state management:

type AppState = {
  user: {
    profile: {
      name: string;
      email: string;
    };
    preferences: {
      theme: 'light' | 'dark';
    };
  };
};

// State should never be mutated directly
const initialState: DeepReadonly<AppState> = {
  // ... state definition
};

Why this matters:

Prevent accidental mutations in state trees
Protect configuration from runtime changes
Make immutability explicit in the type system
Catch bugs at compile time instead of runtime

The `infer` Keyword — TypeScript's "Capture" Tool

This was the part that took me the longest to wrap my head around. I used to think of types as static labels I had to manually apply, but infer changed that. I started seeing it as a Type Detective.

Instead of telling TypeScript what a type is, I'm asking it to go find a type that's hidden inside a structure I've already built.

The Analogy That Fixed It For Me

I found it helpful to think of a sealed box labeled "Container of [Something]".

With standard generics, I'm the one putting the label on: Container<Apple>.
With infer, I'm looking at a box that's already there and saying: "If this is a container, capture whatever is inside it and let me use that value as a new type."

Peeking Under the Hood: `ReturnType`

I realized I had actually been using infer all along without knowing it. The built-in ReturnType<T> utility which we discussed in part 2 isn't a special hard-coded feature; it's just a clever bit of logic in the TypeScript source code that looks like this:

type ReturnType<T> = T extends (...args: any[]) => infer R ? R : any;

I started breaking down the logic like this:

The Match: First, it checks "Is T a function?"
The Capture: If it is, infer R tells TypeScript: "Don't just return true. Reach into the function, grab the specific type it returns, and store it in a temporary variable R."
The Result: Then it simply returns that captured R.

The Real-World "Why": The Single Source of Truth

The moment this actually became useful for me was when I tried to keep my runtime data and my types in sync. I hated typing the same list twice.

For example, if I have a Set of allowed User Roles, I want my Role type to update automatically whenever I change that Set.

// 1. My source of truth (at runtime)
const VALID_ROLES = new Set(['admin', 'editor', 'viewer'] as const);

// 2. My "stolen" type logic
type GetSetValues<T> = T extends Set<infer V> ? V : never;

// 3. Automated Syncing
type Role = GetSetValues<typeof VALID_ROLES>;
// Result: "admin" | "editor" | "viewer"

The breakthrough for me: Now, if I add 'super-admin' to the VALID_ROLES set, my Role type updates instantly. No manual syncing, no room for "type drift."

When I Find Myself Reaching For It

I've started using infer whenever I need to "break into" a type that I didn't define myself:

Unwrapping Promises: Getting the raw data type out of an API call result.
Peeking at Array Items: Finding out what's inside a list without manually re-typing the interface.
Template Literals: Pulling a specific ID or string pattern out of a string like "user_123".

My Mental Shortcut

extends is the condition (the "if").
infer is the grab (the "capture").

Template Literal Types - Type-Safe Strings

The Pattern

// Type-safe filter parameters
type FilterParam = `filter_${string}_single` | `filter_${string}_multi`;

// Valid:
const param1: FilterParam = 'filter_color_single'; // ✅
const param2: FilterParam = 'filter_price_multi'; // ✅

// Invalid:
const param3: FilterParam = 'filter_color_xyz'; // ❌ Error
const param4: FilterParam = 'color_single'; // ❌ Error (missing prefix)

How It Works

Template literal types let us construct types using string patterns:

type Prefix = 'filter_';
type Suffix = '_single' | '_multi';
type FilterParam = `${Prefix}${string}${Suffix}`;

The magic: TypeScript enforces the pattern at compile time.

Real-World Use Cases

1. Event handlers:

type EventName = `on${Capitalize<string>}`;

const handler1: EventName = 'onClick'; // ✅
const handler2: EventName = 'onSubmit'; // ✅
const handler3: EventName = 'click'; // ❌ Error (missing 'on')

2. CSS variables:

type CSSVariable = `--${string}`;

const color: CSSVariable = '--primary-color'; // ✅
const invalid: CSSVariable = 'primary-color'; // ❌ Error

3. API routes:

type APIRoute = `/api/${string}`;

const userRoute: APIRoute = '/api/users'; // ✅
const invalid: APIRoute = '/users'; // ❌ Error

4. Extract admin routes:

type PageType =
  | 'home'
  | 'about'
  | 'admin-dashboard'
  | 'admin-settings'
  | 'admin-users';

// Only admin pages
type AdminPage = Extract<PageType, `admin-${string}`>;
// Result: 'admin-dashboard' | 'admin-settings' | 'admin-users'

The Polymorphic Pattern — Building a "Shape-Shifter"

When this pattern clicked, I realized it's the secret sauce behind every professional UI library like Radix. The same insights I want to share too.

The Problem

I built a standard Button component, and everything was fine. Then a designer asked: "Can this button be a link sometimes?" I tried the obvious approach—adding an href prop and an if statement—but I quickly ran into a mess. My Button was getting link props, and my Link was getting button props. TypeScript was confused, and I was manually writing dozens of optional props.

I wanted a component that could do this:

// This should only allow button props (like type="submit")
<Button as="button" type="submit">Save</Button>

// This should only allow link props (like href="/home")
<Button as="a" href="/home">Home</Button>

How I Simplified the Logic

I realized a polymorphic component is basically a shape-shifter. It needs to look at the as prop and then "steal" the correct HTML attributes for that specific tag.

I broke it down into this mental model:

The Generic Element (E): I tell TypeScript that my component can be any HTML tag.
The as Prop: I pass in the tag name (like 'a' or 'button').
The Prop Thief: I use a built-in React type to "grab" all the valid props for whatever E happens to be.

Peeking at the Magic: `ComponentPropsWithRef`

The real breakthrough for me was discovering ComponentPropsWithRef<E>. It's like an automated dictionary:

If E is 'a', it gives me href.
If E is 'button', it gives me type and disabled.
If E is 'div', it removes both and gives me aria roles.

My "Clean" Implementation

Instead of fighting the types, I found that casting the component as a Polymorphic type at the very end was the cleanest way to keep the code readable.

// I think of this as the "Contract"
type Polymorphic<DefaultElement extends ElementType, CustomProps = {}> =
  E extends ElementType = DefaultElement
>(
  // Combine the 'as' prop + my custom props + the "stolen" HTML props
  props: { as?: E } & CustomProps & ComponentPropsWithRef<E>
) => ReactElement | null;

The Result

When I finally put it all together, the developer experience was incredible. If I try to pass a disabled prop to a Button that is acting as="a", TypeScript catches it immediately:

<Button as="a" href="/dashboard" disabled>
  {/* ❌ Error: 'disabled' doesn't exist on 'a' tags! */}
</Button>

When I Use This (And When I Don't)

I've learned that this is a "power tool."

I use it for: Layout primitives (like a Box or Stack) and design system components (like Button or Heading).
I skip it for: Simple, one-off components. If a component is always going to be a form, there's no need to make it polymorphic.

My rule of thumb: If I find myself writing if (isLink) return <a ... />, it's time to reach for the Polymorphic pattern.

Putting It All Together

Here's how these patterns compose:

// 1. Deep config with immutability
type Config = DeepReadonly<{
  api: {
    baseUrl: string;
    timeout: number;
  };
}>;

// 2. Test overrides
const testConfig: DeepPartial<Config> = {
  api: {
    timeout: 1000,
    // ✅ baseUrl is optional
  },
};

// 3. Type-safe routes
type APIRoute = `/api/${string}`;
type AdminRoute = Extract<APIRoute, `/api/admin-${string}`>;

// 4. Set-based types
const validRoutes = new Set(['/api/users', '/api/products'] as const);
type SetValues<S> = S extends Set<infer V> ? V : never;
type ValidRoute = SetValues<typeof validRoutes>;

// 5. Polymorphic component
const Link = forwardRef(({ ...props }, ref) => <a ref={ref} {...props} />);
export const StyledLink = Link as Polymorphic<'a', { variant: 'primary' | 'secondary' }>;

Quick Reference

Pattern	Syntax	Use Case
DeepPartial	`T extends object ? { [P]?: DeepPartial } : T`	Nested config overrides
DeepReadonly	`T extends Function ? T : readonly`	Immutable state trees
infer (Set)	`S extends Set<infer V> ? V : never`	Extract Set value types
infer (Promise)	`T extends Promise<infer U> ? U : T`	Unwrap Promise types
Template Literals	`${Prefix}${string}${Suffix}`	Type-safe string patterns
Polymorphic	`<E extends ElementType>(props) => Element`	Flexible React components

Wrapping Up

What we built:

✅ DeepPartial<T> - Recursive optional properties
✅ DeepReadonly<T> - Recursive immutability
✅ infer pattern - Capturing types from generics
✅ Template literal types - Type-safe string patterns
✅ Polymorphic pattern - How component libraries work

Key takeaways:

Built-in utilities are shallow - we need custom ones for deep problems
infer lets us capture and extract types dynamically
Template literals enable compile-time string validation
Polymorphic is how libraries stay flexible AND type-safe
These patterns compose - mix and match to solve complex problems

The Journey

We started with basic sculptors (Record, Pick, Omit).

Evolved to transformers and thieves (Partial, ReturnType, Parameters).

Ended by building our own utilities and understanding what powers modern TypeScript libraries.

We now have tools to:

Write type-safe, maintainable code
Build custom utility types when needed
Read advanced TypeScript codebases
Contribute to component libraries confidently

Final Thought

TypeScript's type system isn't just about catching bugs. It's about encoding our intent so clearly that code documents itself.

When we use DeepReadonly on a config, we're saying: "This should never change at runtime."

When we use Polymorphic on a Button, we're saying: "This can be many things, but always safely."

That's the real power.

Until next time, happy typing! Pranipat 🙏! ☮️

Questions about advanced TypeScript patterns? Want to discuss these utilities? Drop a comment! 🚀

Mastering TypeScript Utility Types: Part 2 — The Transformers & Type Thieves

Manuj Sankrit — Sun, 25 Jan 2026 09:36:11 +0000

If you recall in Part 1, we covered the basics—Record, NonNullable, Pick, and Omit. The "sculptors" that help us shape our types.

Today? We're going deeper.

I remember the first time I used Partial<T> in a test utility. Thought it was neat. Then I discovered ReturnType<T> and Parameters<T>. Post this I haven't manually typed a function's return value since. These utilities don't just save us typing—they make it impossible for our types to drift out of sync with our actual code.

In this article, I will share my insights which is all about the Transformers & Type Thieves🤠. Utilities that automatically change existing types or straight-up "steal" type information from our functions.

Mental Model:

TRANSFORMERS           TYPE THIEVES
-----------            ------------
Partial<T>      →      ReturnType<T>
Required<T>     →      Parameters<T>
Exclude<T, U>
Extract<T, U>

Transform what         Steal from what
we already have       already exists

The Transformers

1. `Partial<T>`

Here's the thing that used to drive me crazy:

Writing tests without Partial is painful.

// We've got this complex interface
interface FetchOptions {
  timeout: number;
  retries: number;
  cache: 'force-cache' | 'no-store' | 'default';
  headers: Record<string, string>;
}

// And every single test needs ALL of it
function fetchData(url: string, options: FetchOptions) {
  // ...implemenetation
}

// So we end up doing this:
fetchData('/api/users', {
  timeout: 5000,
  retries: 3,
  cache: 'default',
  headers: {},
});
// Like... we literally only care about timeout here 😭

In every test file we have to copy-paste which was really tedious. And when we add a new property to that interface? Cool, now go update 47 test files.

Here's what changed everything:

// Just make everything optional and use defaults
function fetchData(url: string, options: Partial<FetchOptions> = {}) {
  const defaults: FetchOptions = {
    timeout: 5000,
    retries: 3,
    cache: 'default',
    headers: {},
  };

  const finalOptions = { ...defaults, ...options };
  // ...implementation
}

// Now in tests:
fetchData('/api/users', { timeout: 10000 });
// ✅ Done. Just what we need.

Partial<T> just makes every property optional. It's like adding ? after every field. But we don't have to type it all out.

How we actually use this in our projects:

type TestOptions = {
  timeout: number;
  retries: number;
  mockData: boolean;
  verbose: boolean;
};

const defaultTestOptions: TestOptions = {
  timeout: 5000,
  retries: 3,
  mockData: false,
  verbose: false,
};

export const runTest = async (
  testName: string,
  testFn: () => Promise<void>,
  options?: Partial<TestOptions>, // ← Here
): Promise<TestResult> => {
  const finalOptions = {
    ...defaultTestOptions,
    ...options,
  };

  // ... rest of implementation
};

// Clean. Simple. Beautiful.
await runTest('user authentication', testUserAuth);
// or when we need to override something:
await runTest('user authentication', testUserAuth, { verbose: true });

Real stuff we can build with this:

Mock factories for tests:

function createMockDOMRect(overrides: Partial<DOMRect> = {}): DOMRect {
  return {
    bottom: 0,
    top: 0,
    left: 0,
    right: 0,
    width: 0,
    height: 0,
    x: 0,
    y: 0,
    toJSON: () => ({}),
    ...overrides,
  };
}

// Just override what we need:
const rect = createMockDOMRect({ bottom: 100, width: 200 });

Update functions (partial state updates):

function updateUserProfile(id: string, updates: Partial<UserProfile>) {
  const currentUser = getUserById(id);
  return { ...currentUser, ...updates };
}

// Clean partial updates:
updateUserProfile('123', { email: 'new@email.com' });

When to reach for it: Anytime we've got sensible defaults and want to override just what we need.

2. `Required<T>`

If Partial is about flexibility, Required is about validation. I thought of it like a Security Checkpoint. We might start with a "loose" object where everything is optional (like a web form while the user is still typing). But before we hit "Submit" and send that data to our database, we need to ensure everyone has their ID and tickets ready.

interface UserRegistrationForm {
  name?: string;
  email?: string;
  password?: string;
  confirmPassword?: string;
}

/**
 * The Gatekeeper:
 * Using a "Type Predicate" (form is Required<...>)
 */
function validateRegistration(
  form: UserRegistrationForm,
): form is Required<UserRegistrationForm> {
  // We check if all fields actually have values
  return !!(form.name && form.email && form.password && form.confirmPassword);
}

function submitRegistration(form: Required<UserRegistrationForm>) {
  // TypeScript knows ALL fields exist here.
  // No more optional chaining (form.name?) or 'if' checks needed!
  console.log(form.name.toUpperCase());
}

The Secret Sauce: The Type Predicate (is)

You'll notice that strange syntax in the return type: form is Required<UserRegistrationForm>. This is called a Type Predicate. Normally, a function returns true or false, and TypeScript just sees it as a simple boolean. But by using is, we are signing a contract with the compiler. We're saying:

"Hey TypeScript, if this function returns true, I promise you that this form variable is no longer optional—it is now officially Required."

Why this is a game-changer: Without that is keyword, even if our function returned true, TypeScript would still be worried that name might be undefined inside the next block of code. The Type Predicate "promotes" our data from untrusted to fully verified, allowing us to write much cleaner logic in our success handlers.

When to reach for it:

Final form submissions
Validating API payloads before processing
Turning "loose" user input into "strict" system data

3. `Exclude<T, U>`

The problem:

We've got a union representing all possible states. But some functions can't handle all of them.

// Every page type in our app
type PageType =
  | 'home'
  | 'about'
  | 'products'
  | 'blog'
  | 'contact'
  | 'admin-dashboard'
  | 'admin-settings';

// Public routes shouldn't show admin stuff
// So we do this:
type PublicPageType = 'home' | 'about' | 'products' | 'blog' | 'contact';
// ❌ Now we've got duplication. PageType changes? Gotta update this too.

Not ideal.

Better way:

// Just filter out what we don't want
type PublicPageType = Exclude<PageType, 'admin-dashboard' | 'admin-settings'>;
// We can also do it like which is much cleaner
// type PublicPageType = Exclude<PageType, 'admin-${string}`>;
// Result: 'home' | 'about' | 'products' | 'blog' | 'contact'

Exclude<T, U> removes types from a union. Think of it like Array.filter() but for types. It keeps everything EXCEPT what we specify.

How we use this in routing:

const validPageTypes = [
  'home',
  'about',
  'products',
  'blog',
  'contact',
  'admin-dashboard',
  'admin-settings',
] as const;

type AllPageTypes = (typeof validPageTypes)[number];

// Hide admin from public
type PublicPageType = Exclude<PageType, `admin-${string}`>;

// Validation helper
function isPublicPageType(pageType: string): pageType is PublicPageTypes {
  const publicTypes: PublicPageTypes[] = [
    'home',
    'about',
    'products',
    'blog',
    'contact',
  ];
  return publicTypes.includes(pageType as PublicPageTypes);
}

Other places this saves us:

State machines (removing final states):

    type OrderStatus =
      | 'pending'
      | 'processing'
      | 'shipped'
      | 'delivered'
      | 'cancelled';

    // Only active orders can be modified
    type ActiveOrderStatus = Exclude<OrderStatus, 'cancelled' | 'delivered'>;

    function canModifyOrder(status: OrderStatus): status is ActiveOrderStatus {
      const activeStatuses: ActiveOrderStatus[] = [
        'pending',
        'processing',
        'shipped',
      ];
      return activeStatuses.includes(status as ActiveOrderStatus);
    }

4. `Extract<T, U>`

If Exclude is a bouncer kicking types out, Extract is a magnet. We hover it over a giant pile of types, and it only pulls out the ones that match our pattern.

The "Wildcard" Pattern:

This is where TypeScript gets really smart. Instead of picking types one by one, we can use Template Literal Types to "search" for a pattern.

type PageType =
  | 'home'
  | 'about'
  | 'products'
  | 'blog'
  | 'contact'
  | 'admin-dashboard'
  | 'admin-settings';

// Using a "Wildcard" to get just the admin pages
type AdminPageType = Extract<PageType, `admin-${string}`>;
// Result: 'admin-dashboard' | 'admin-settings'

Why this is "Human-Friendly" code:

We are future-proofing our app. If we add 'admin-users' or 'admin-reports' to our PageType next month, our AdminPageType will automatically "magnetize" them. We don't have to change our code in two places!

Another useful pattern (Filtering Keys):

interface User {
  id: number;
  name: string;
  email: string;
  createdAt: Date;
}

// Only pull out the keys we want to display in a specific UI
type DisplayKeys = Extract<keyof User, 'name' | 'email'>;
// Result: 'name' | 'email'

The Type Thieves

Okay, this is where it gets fun. Instead of writing types manually, we're gonna make TypeScript steal them from existing code.

5. `ReturnType<T>`

The old way (painful):

function getProductData(id: string) {
  return {
    id,
    name: 'Widget',
    price: 99.99,
    inStock: true,
    metadata: {
      weight: 1.5,
      dimensions: { width: 10, height: 5, depth: 3 },
    },
  };
}

// Need this type somewhere else...
// So we do this:
interface ProductData {
  id: string;
  name: string;
  price: number;
  inStock: boolean;
  metadata: {
    weight: number;
    dimensions: {
      width: number;
      height: number;
      depth: number;
    };
  };
}
// ❌ Duplication. Change the function? Update this interface too. This is asking for bugs.

The new way (beautiful):

function getProductData(id: string) {
  return {
    id,
    name: 'Widget',
    price: 99.99,
    inStock: true,
    metadata: {
      weight: 1.5,
      dimensions: { width: 10, height: 5, depth: 3 },
    },
  };
}

// Just steal the return type:
type ProductData = ReturnType<typeof getProductData>;
// ✅ Done. **Automatically synced forever.**

Changed the function? The type updates automatically. No manual work.

Real example from our API layer:

For this to work cleanly, we need a discriminated union where success and error states are distinct:

// API call with discriminated union return type
async function fetchProductsFromAPI(productIds: string[]) {
  try {
    const response = await fetch('/api/products', {
      method: 'POST',
      body: JSON.stringify({ productIds }),
    });

    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`);
    }

    const data = await response.json();
    // Success case
    return { success: true, products: data.products ?? [] } as const;
  } catch (err) {
    // Error case
    return { success: false, error: err as Error } as const;
  }
}

// Steal the return type:
type ApiProductsResponse = Awaited<ReturnType<typeof fetchProductsFromAPI>>;
// Result: { success: true, products: Product[] } | { success: false, error: Error }

// Extract just the success case:
type SuccessResponse = Extract<ApiProductsResponse, { success: true }>;
// **TypeScript now knows:** { success: true, products: Product[] }

// Extract just the error case:
type ErrorResponse = Extract<ApiProductsResponse, { success: false }>;
// **TypeScript now knows:** { success: false, error: Error }

Where else we use this:

Redux action creators:

function createProductAction(id: string, name: string) {
  return {
    type: 'ADD_PRODUCT' as const,
    payload: { id, name },
  };
}

type ProductAction = ReturnType<typeof createProductAction>;
// Result: { type: 'ADD_PRODUCT'; payload: { id: string; name: string } }

// Reducer **automatically knows the shape:**
function productReducer(state: State, action: ProductAction) {
  // TypeScript knows action.type and action.payload
}

Form validators:

function validateUserForm(form: FormData) {
  const errors: string[] = [];
  if (!form.email) errors.push('Email required');
  if (!form.password) errors.push('Password required');

  return {
    isValid: errors.length === 0,
    errors,
  };
}

type ValidationResult = ReturnType<typeof validateUserForm>;

// Use in component:
const [validation, setValidation] = useState<ValidationResult | null>(null);

When to use it: Literally anytime we need a function's return type elsewhere. One source of truth.

Bonus - combine with Awaited for async:

async function fetchUser(id: string) {
  const response = await fetch(`/api/users/${id}`);
  return response.json();
}

// Get the resolved type (unwrap the Promise):
type User = Awaited<ReturnType<typeof fetchUser>>;

6. `Parameters<T>`

Same problem, different angle:

function createUser(
  name: string,
  email: string,
  age: number,
  role: 'admin' | 'user',
) {
  // ... implementation
}

// Need these param types somewhere else
// Manual way:
type CreateUserParams = {
  name: string;
  email: string;
  age: number;
  role: 'admin' | 'user';
};
// ❌ Function signature changes? Update this manually.

Better:

function createUser(
  name: string,
  email: string,
  age: number,
  role: 'admin' | 'user',
) {
  // ... implementation
}

// Steal the params:
type CreateUserParams = Parameters<typeof createUser>;
// Result: [string, string, number, 'admin' | 'user']

// Grab individual ones:
type UserName = Parameters<typeof createUser>[0]; // string
type UserRole = Parameters<typeof createUser>[3]; // 'admin' | 'user'

Real usage - wrapper functions:

This is where Parameters really shines—when we need to preserve exact type signatures:

function logAndExecute<T extends (...args: any[]) => any>(
  fn: T,
  ...args: Parameters<T>
): ReturnType<T> {
  console.log(`Calling ${fn.name} with`, args);
  return fn(...args);
}

// Usage:
function add(a: number, b: number): number {
  return a + b;
}

const result = logAndExecute(add, 5, 10);
// **TypeScript automatically knows:**
// - Parameters<typeof add> = [number, number]
// - ReturnType<typeof add> = number

Another example - event handlers:

const handleSubmit = (event: React.FormEvent<HTMLFormElement>) => {
  event.preventDefault();
  // ...
};

type SubmitEventParams = Parameters<typeof handleSubmit>;
// Result: [React.FormEvent<HTMLFormElement>]
// Use when passing the handler around

When to use it: Anytime we need function parameter types. Stop duplicating.

⚡️ Bonus Round: The "Ghost" vs. The "Mold"

In Part 1, I mentioned Zod. When we combine Zod with ReturnType, we get the "Holy Grail" of coding: Single Source of Truth.

import { z } from 'zod';

// 1. THE MOLD (Runtime Reality)
const UserSchema = z.object({
  name: z.string().min(5), // Let's require 5+ characters
  email: z.string().email(),
});

// 2. THE GHOST (TypeScript Blueprint)
// Zod "steals" the shape of the mold and gives it to the Ghost.
type User = z.infer<typeof UserSchema>;

function submitUser(data: User) {
  // Layer 1: The Ghost (TS) catches typos while we code.
  // Layer 2: The Mold (Zod) catches fake data while the app runs.
  return UserSchema.parse(data);
}

// 3. THE LOGBOOK (Utility Type)
// We "steal" the final, validated return type.
type SubmitUserReturn = ReturnType<typeof submitUser>;

Why this is beautiful: Think of TypeScript as a Ghost—it can see our code but it can't touch the real world. Think of Zod as a Mold—it's a physical check that sits in the real world.

By using z.infer and ReturnType, we lock the Ghost and the Mold together. If we change the Mold (the schema), the Ghost (the types) updates automatically. No manual interface updates, no sync errors, just pure automation.

Quick Cheat Sheet

Utility	Does What	Mental Model
`Partial<T>`	Makes everything optional	Transform: all props → optional
`Required<T>`	Makes everything required	Transform: all props → required
`Exclude<T, U>`	Remove types from union	Filter OUT these types
`Extract<T, U>`	Keep only matching types	SELECT only these types
`ReturnType<T>`	Steal function return type	Thief: grab what function returns
`Parameters<T>`	Steal function params	Thief: grab what function accepts
`Awaited<T>`	Unwrap Promise	Thief: grab Promise's resolved type

That's It

Stop writing types twice. Let TypeScript infer.
Partial + defaults = clean, flexible code
Exclude/Extract = type-safe state machines
ReturnType/Parameters = single source of truth

Up Next: Part 3

Built-in utilities are great but sometimes they're not enough.

In next and last part of this series I will share my insights on:

DeepPartial<T> - When Partial only goes one level
DeepReadonly<T> - Immutability all the way down
Polymorphic<T, Props> - The holy grail for flexible React components
Template Literal Types - Type-safe string patterns
Building our own - Mapped types, conditional types, infer

We'll build DeepPartial from scratch, break down the Polymorphic pattern step-by-step, and explore what powers libraries like Radix UI and others.

See you then. Happy typing! Pranipat 🙏! ☮️

Questions? Using these in production? Let me know in the comments! 🚀

Dependency Rollercoaster: Navigating the NPM Theme Park

Manuj Sankrit — Mon, 12 Jan 2026 05:12:15 +0000

The "Aha!" Moment That Started It All

I was implementing a new feature, feeling like a code wizard 🧙‍♂️. I submitted the PR, and then my TL drops a comment that sounds like it's in a foreign language:

You need to add these as peer dependencies so the consuming app can install them.

Wait, what? 🤔

I stared at my screen. I'd been using dependencies and devDependencies since I started with Node, but peer dependencies? And why do I need to install react-hook-form when neither the library I am using has it as a direct dependency, nor am I using it directly?

That confusion led me down a rabbit hole that transformed how I understand npm's dependency ecosystem. It turns out, managing a package.json is a lot like running an Amusement Park.

🎢 The Four Zones of Dependency Park

Recently, I took my nephew to an amusement park and derived the analogy so that the concept stays in my brain for long, therefore; I will be using this analogy. Let us think of our project as a world-class theme park. To keep the rides running and the guests happy, we need different types of resources.

1. Dependencies — The Main Attractions

"dependencies": {
  "react": "^18.2.0",
  "axios": "^1.6.0"
}

What? These are the actual Rollercoasters. If the 'Big Loop' package isn't there, the park isn't a theme park—it’s just an empty parking lot.

When to use: Any package our code directly "rides" (imports) and needs at runtime to function for the guests.

The Rule: These get installed automatically. If we don't have these, the park is closed(code won't work in production).

2. DevDependencies — The Maintenance Crew

"devDependencies": {
  "jest": "^29.0.0",
  "eslint": "^8.0.0",
  "typescript": "^5.0.0"
}

What? The hard hats, the wrenches, and the blueprints. The guests don't see them, but we can't build or repair the rollercoaster without them.

When to use: Tools for development, testing, building, or linting (like Jest, ESLint, or Vite).

The Rule: These are NOT installed when someone visits our park (installs our package as a library). They only exist at the construction site (our local machine).

3. PeerDependencies — The "Bring Your Own Gear" Requirement

"peerDependencies": {
  "react": "^18.0.0",
  "react-dom": "^18.0.0"
}

What? This is the "Requirement" sign at the entrance of a ride. Imagine a water slide that says: "We provide the slide, but YOU must bring your own swimsuit."

The "Aha!" Moment: This is where I got stuck!

Our component library is the water slide. If we bundled a swimsuit with every single slide (put React in dependencies), the park would be full of redundant, soggy clothes that don't fit the guests (Bundle Bloat and Version Conflicts).

Instead, we just check at the gate: "Do you have a swimsuit (React 19)?" Our library expects the host environment to already have this package installed.

The Chain Mystery: This is the "Hidden Requirement" through Transitive Peer Dependencies.

If our slide uses a specific floatie (another library say awesome-form-components), and that floatie requires a pump (react-hook-form), the guest suddenly needs both! Even though our library doesn't use the react-hook-form(pump as per our analogy) directly, the consuming application must install it.

The Dependency Chain:

Main App (The Guest)
  └── My Library (The Slide)
        └── awesome-form-components (The Floatie)
              └── [PEER] react-hook-form (The Pump) 🚩
                                  ↓
Result: Main App must install react-hook-form

If it doesn't, npm throws a Peer Dependency Resolution Error.

When to use:

Plugins & UI Kits: Our code "plugs into" a larger framework (React, Vue, Tailwind)
Singleton Enforcement: Only one instance of a package can exist (two React versions = broken app)
Version Flexibility: Let developers use any compatible version within our specified range

4. OptionalDependencies — The VIP Fast Pass

"optionalDependencies": {
  "fsevents": "^2.3.0"
}

What? The "nice-to-have" extras. Maybe it's a heated seat on the log flume. If the heater is out of stock, the ride still works—it's just a bit colder.

When to use: Platform-specific optimizations (like macOS-only features).

The Rule: If installation fails, npm just shrugs and keeps going. Your code should handle the "empty seat" gracefully!

The Supply Chain Drama (Transitive Dependencies)

Transitive dependencies are the "dependencies of our dependencies."

Let us imagine it as the supply chain for our park. We bought a Rollercoaster (Direct), but that rollercoaster was built using a specific brand of bolts and grease (Transitive). We didn't order the bolts, but they are in our park now!

Your Park (Project)
 ├── Rollercoaster (Direct)
 │    ├── Specialized Bolts (Transitive)
 │    └── Industrial Grease (Transitive)

The Danger: If those bolts have a safety recall (security vulnerability), your whole ride is at risk, even though you never talked to the bolt manufacturer.

Quick Reference Guide

Type	Installed When?	The Analogy
dependencies	Always	The Rides (Essential)
devDependencies	Local only	The Tools (Construction)
peerDependencies	By the User	The Gear (Swimsuits/Helmets)
optionalDependencies	If possible	The VIP Perks (Extras)

Real-World Tips from the Trenches

Building a library? Use peerDependencies for framework packages and not force our version of React on our users! It would provide more flexibility to our users along with compacting the bundle size.
Seeing duplicates? Run npm dedupe or yarn dedupe to make sure our park isn't storing five copies of the same "bolt."
Lock it down: Always commit package-lock.json. It's the "As-Built" blueprint that ensures the park looks the same for every developer(everyone using our app has same version of dependencies).

🔢 The Version Symphony: ^ vs ~ vs Exact

Most of us are aware of this but just to provide an overall guide let us take a quick look at how versioning works. How do we tell our suppliers which parts to send? We use symbols.

Symbol	Name	Meaning	Example	Accepts	Rejects
^	Caret	Minor + Patch	`^1.2.3`	1.2.3, 1.3.0, 1.9.9	2.0.0
~	Tilde	Patch only	`~1.2.3`	1.2.3, 1.2.4, 1.2.9	1.3.0
None	Exact	Exact match	`1.2.3`	1.2.3 only	1.2.4
>=	Range	Greater/equal	`>=1.2.0 <2.0.0`	1.2.0 - 1.99.99	2.0.0+

🔮 What's Next? Part 2: The Transpile Adventure

Understanding the logic is one thing. But what happens when we buy a high-performance 15A Geyser (ESM) and try to force it into a standard 5A Bedroom Socket (CommonJS)?

Suddenly, our project "trips the circuit" and we get the dreaded: SyntaxError: Cannot use import statement outside a module

In Part 2, I’ll share my insights into the technical "wiring" of our project:

15A vs 5A: Why ESM and CommonJS don't just "plug and play."
The Short Circuit: Why our build breaks even when our code logic is perfect.
The Heavy-Duty Adapter: Solving the mystery of transpilePackages.

Stay tuned! We’re about to fix the wiring next ⚡. Till then Pranipat🙏

Mastering TypeScript Utility Types: Part 1 — The Sculptors

Manuj Sankrit — Mon, 05 Jan 2026 05:24:02 +0000

When I started working on frontend projects especially around the React ecosystem, I used Vanilla javascript. Typescript was getting the traction to be used on frontend projects. From that time on to 3 years down the line working with Typescript, I used to think that I am pretty good at it. But when I discovered utility types, I realized I'd been coding with one hand tied behind my back.

I'm working on a large-scale NextJs application. To paint a specific picture, we're talking 98.8% TypeScript (yes, we're that serious about types). For months before exploring the utility types, I was copying-pasting type definitions, wrestling with nullable API responses, building components that needed 50 different prop combinations just to handle a button that sometimes needs to be a link.

When working on a feature which involved GQL and integrating one of the custom components, I saw these types; became curious and decided to master them and voilà!! everything changed.

Today, I'm kicking off a 3-part series on the utility types I reach for every single day. Over these three articles, I'll share my learning around them and we'll look at real-world patterns from production code—not contrived tutorials. These aren't just fancy tricks; they are the workhorses that solve 80% of my type-related headaches.

In this first part, we’re focusing on the Foundational Sculptors: the four utilities you need to turn messy, unpredictable data into a rock-solid contract.

The Foundation: Sculpting Your Data

1. `Record<K, T>`

The Pain:

Every time I needed a lookup table or enum-like object, I'd write this:

// ❌ Before - No type safety, just vibes
const environments: { [key: string]: string } = {
  DEVELOPMENT: 'DEVELOPMENT',
  STAGING: 'STAGING',
  TYPO: 'STAGGING', // Oops! No error, just a runtime bug waiting to happen
};

// Later in code...
const env = environments['PRODUTION']; // undefined, but TypeScript is chill about it

TypeScript accepts this, but if you analyze it, it's nothing but any with extra steps. The keys aren't validated. The values aren't validated. It's simply type-safety drama.

The Solution:

// ✅ After - Type-safe keys AND values
type Environment = 'DEVELOPMENT' | 'STAGING' | 'PRODUCTION';

export const ENVIRONMENTS: Record<Environment, Environment> = {
  DEVELOPMENT: 'DEVELOPMENT',
  STAGING: 'STAGING',
  PRODUCTION: 'PRODUCTION',
  TYPO: 'DEV',
  // ❌ TypeScript error: Type '"TYPO"' is not assignable to type 'DEVELOPMENT' | 'STAGING' | 'PRODUCTION'
};

// Now this is also caught:
const ENVIRONMENTS: Record<Environment, Environment> = {
  DEVELOPMENT: 'dev',
  // ❌ Error: Type '"dev"' is not assignable to type 'Environment'
};

Real Use Cases:

Configuration objects with known keys
Enum-like lookups
Mapping IDs to data structures
Feature flags

When to use: You know all possible keys in advance and need type-safe values.

Ninja Tip - Level Up:

Combine Record with const arrays for maximum type safety:

const STATUSES = ['pending', 'approved', 'rejected'] as const;
type Status = (typeof STATUSES)[number];
// Result: 'pending' | 'approved' | 'rejected'

type StatusConfig = {
  label: string;
  color: string;
};

type StatusMap = Record<Status, StatusConfig>;
// Now TypeScript enforces you define ALL statuses:

const statusMap: StatusMap = {
  pending: { label: 'Pending', color: 'yellow' },
  approved: { label: 'Approved', color: 'green' },
  // ❌ Error: Property 'rejected' is missing
};

Single source of truth + compile-time validation = chef's kiss. 👨‍🍳💋

2. `NonNullable<T>`

The Pain:

If you've worked with GraphQL or REST APIs, you know this pain:

// API response structure (everything is nullable, why not?)
type ApiResponse = {
  data?: {
    user?: {
      posts?: {
        title?: string;
      }[];
    };
  };
};

// Accessing nested data becomes optional chaining hell:
const title = response?.data?.user?.posts?.[0]?.title;
//                    ^      ^    ^      ^    ^
//            Question marks everywhere. My code looks confused.

// And the type is: string | undefined | undefined | undefined...
// (TypeScript is just as confused as my code looks)

Every time you access a property, you're playing Russian roulette with undefined.

Under the Hood: Thinking like a Typescript compiler

Before talking about the solution, I would like to bring our understanding on the same page. We would need to understand how NonNullable<T> works. For that let us take a detour and understand this with the perspective of typescript compiler.

Step 1: Understanding the union

As you're already aware that if you're defining something with ? or potentially null, you're creating a Union type. Think of it with a variable that represents a box which holds different "chocolates": type chocolateName = string | null | undefined

This means the box can contain a string(chocolateName), OR it can be empty (null), OR it hasn't even been touched(initialized) yet (undefined).

Step 2: The Filter Logic

NonNullable<T> is a "Filter." It looks at the above Union Type and says: "I will keep everything EXCEPT null and undefined."

To make my point more clear, we can think the definition of NonNullable<T> to be something like:

type NonNullable<T> = T extends null | undefined ? never : T;

Translation: "If the type T is null or undefined, throw it away (never). Otherwise, keep the type T.

Step 3: The "Unwrapping" Process

Let's look at our API example. If we have type User = { name?: string | null }, the type of User['name'] is technically string | null | undefined.

When you run type CleanName = NonNullable<User['name']>, the compiler performs this check:

Is string null or undefined? No. → Keep it.
Is null null or undefined? Yes. → Discard it.
Is undefined null or undefined? Yes. → Discard it.

Result: CleanName is now just string.

Step 4: The "Deep Unwrapping" Pipeline

When you have a deeply nested object, you have to unwrap it layer by layer. You can't just jump to the bottom because if the "parent" is null, the "child" doesn't even exist yet.

Caveat: When you use NonNullable, you're making a promise to the compiler that I know this API contract says a particular property might be null, but by the time it gets here(onto the line number where you used it), it's not. If the API actually returns null at runtime, the compiler won't save your app from a crash. This is why we generally use NonNullable in conjunction with Input validator libraries like Zod to ensure our promise to the compiler is kept.

The Solution:

// Step 1: Create a helper alias (trust me on this)
type NN<T> = NonNullable<T>;

// Step 2: Chain unwrapping from the top down
type ApiData = NN<ApiResponse['data']>;
//             ^^^ Removes | undefined | null

type UserData = NN<ApiData['user']>;
//              ^^^ user is no longer optional

type PostsData = NN<UserData['posts']>;
//                          ^^^^^^^^ Get type of array elements

type Post = NN<PostsData[number]>;

type PostTitle = NN<Post['title']>;
// Final result: string ✨
// No question marks, no uncertainty, just clean string

Real Pattern from Production:

This is literally from my codebase (simplified and masked 😎):

import { GetUserPostsQuery } from './graphql.generated';

type NN<T> = NonNullable<T>;

type QueryData = NN<GetUserPostsQuery>;

type UserData = NN<QueryData['user']>;

type PostsData = NN<UserData['posts']>;

type Post = NN<PostsData[number]>;

// Now I can confidently use Post without any optional chaining
// It's guaranteed to have the shape I expect

When to use:

API responses (GraphQL, REST, etc.)
Any time you see Type | null | undefined and you KNOW it exists
Unwrapping deeply nested optional structures

Ninja Tip - Save Your Sanity:

Create the NN<T> alias at the top of your types file. Your future self (and your teammates) will thank you (just like I keep thanking my project architects):

// types/api.ts
export type NN<T> = NonNullable<T>;

// Now everywhere:
import type { NN } from '@/types/api';
type CleanData = NN<MessyApiResponse['data']>;

Three characters instead of fourteen. You're welcome. 😎

3. `Pick<T, K>` & `Omit<T, K>`

These two work together like salt and sugar. They're opposites that balance each other.

The Pain:

// You have a massive User type
interface User {
  id: string;
  name: string;
  email: string;
  password: string;
  ssn: string;
  creditCard: string;
  address: string;
  phone: string;
  createdAt: Date;
  updatedAt: Date;
  lastLogin: Date;
}

// You need different versions for different contexts:
// - User profile (name, email only)
// - Public user (everything except sensitive data)
// - User DTO (no date objects)

// Copy-paste hell begins...
interface UserProfile {
  name: string;
  email: string;
}
// Every time User changes, update this manually 😭

The Solution:

`Pick<T, K>` - Extract only what you need

// Extract specific properties
type UserProfile = Pick<User, 'name' | 'email'>;
// Result: { name: string, email: string }

// Component props from larger type
interface ProductData {
  id: string;
  name: string;
  price: number;
  description: string;
  images: string[];
  inventory: number;
  weight: number;
  dimensions: { width: number; height: number; depth: number };
  manufacturer: string;
  // ... 20 more fields
}

// Your component only needs these 3
type ProductCardProps = Pick<ProductData, 'name' | 'price' | 'images'>;

function ProductCard({ name, price, images }: ProductCardProps) {
  // Clean, focused component
}

`Omit<T, K>` - Remove what you don't want

// Remove sensitive fields
type PublicUser = Omit<User, 'password' | 'ssn' | 'creditCard'>;
// Result: User without the dangerous stuff

// API DTO (no Date objects, they don't serialize well)
type UserDTO = Omit<User, 'createdAt' | 'updatedAt' | 'lastLogin'>;

When to use:

Pick: Extracting a subset (component props, DTOs, focused views)
Omit: Removing sensitive/unwanted fields (public APIs, sanitization)

The Marie Kondo Rule™:

"Does this property spark joy in this context? No? Omit it."

Ninja Tip - They Compose:

Just like we use salt and sugar together to prepare delicious Gujarati Dal 😋

// Pick some fields, THEN omit from those
type EditableUserProfile = Omit<Pick<User, 'name' | 'email' | 'id'>, 'id'>;
// Result: { name: string, email: string }
// (We picked 3, then removed id)

// This is the same as:
type EditableUserProfile = Pick<User, 'name' | 'email'>;
// But sometimes the composed version is clearer for complex scenarios

Real-World Pattern:

// Base props
interface BaseButtonProps {
  variant: 'primary' | 'secondary';
  size: 'sm' | 'md' | 'lg';
  onClick: () => void;
  disabled: boolean;
}

// Icon button doesn't need size (icon is always sized to content)
type IconButtonProps = Omit<BaseButtonProps, 'size'>;

// Link button needs href, not onClick
type LinkButtonProps = Omit<BaseButtonProps, 'onClick'> & {
  href: string;
};

Wrap Up

We've covered the four "sculpting" tools that will handle the majority of your daily TypeScript friction. Here is the quick-reference guide for when to reach for which tool:

Utility	The Metaphor	Best Used For...
`Record<K, T>`	The Dictionary	Locking down lookup tables and config objects.
`NonNullable<T>`	The Filter	Cleaning up "Question Mark Staircase" API responses.
`Pick<T, K>`	The Salt	Extracting specific properties for focused UI components.
`Omit<T, K>`	The Sugar	Removing sensitive or unwanted fields from a large object.

Final Thought: Trust Your Tools

Mastering these four utilities isn't just about writing less code—it's about writing predictable code. When you use NonNullable to unwrap an API response or Record to define your environment variables, you are removing the "guessing game" from your development process. You're moving the errors from your user's browser back to your code editor, where they belong.

What's Next in Part 2? 🚀

Now that we've mastered the art of "sculpting" existing data, it's time to move into automation and transformation.

In Part 2 of this series, we'll move beyond the basics to look at how we can make our types dynamic and reusable. We will cover:

Partial<T>: Why this is the secret weapon for unit testing and mock factories.
Exclude<T, U>: The "Bouncer" for your state machines and Union types.
ReturnType<T> & Parameters<T>: The magic of "stealing" types directly from your functions so you never have to write a manual interface again.

Found this helpful? Let me know in the comments—and if you use any of these patterns, I'd love to hear about it! 🚀

Until then, Pranipat🙏! ☮️

Forem: Manuj Sankrit

Page Numbers Lie: Offset vs Cursor Pagination

From Interview Notes To Production Reality

First — What Even Is Pagination?

Offset-Based Pagination

The Idea

The Skipped Item Problem

The Duplicate Item Problem

Why This Happens

When Offset Is Still The Right Choice

Cursor-Based Pagination

The Idea

Why Cursors Fix The Offset Problems

What Is An Opaque Cursor?

The Trade-Off You Give Up

Relay: The Standard That Formalised Cursors

Side By Side

How To Choose

Wrapping Up

Which promise method do you need?

The Quick Cheat Sheet (For the Impatient 😄)

The Decision Framework

Promise.all

What it does

When to use it

Polyfill

Promise.any

What it does

When to use it

Polyfill

Promise.race

What it does

When to use it

Polyfill

Promise.allSettled

What it does

When to use it

Polyfill

The Side-by-Side That Makes It Click

Common Mistakes (That I've Also Made 😅)

Quick Reference

Handy Bit Manipulation Tricks

Basic Bit Operations

Setting a Bit

Clearing a Bit

Toggling a Bit

Checking a Bit

Some Clever Tricks

Check if a Number is a Power of 2

Count Set Bits (Brian Kernighan's Algorithm)

Find the Rightmost Set Bit

Swap Two Numbers Without a Temp Variable

Check if a Number is Even

The Trade-off: Efficiency vs Readability

Where This Actually Matters

Quick Reference

Mastering TypeScript Utility Types: Part 3 — Building Custom Utilities

The Problem: Built-ins Don't Go Deep Enough

Building DeepPartial<T> - The Journey

Step 1: Starting Point

Step 2: What If We Just... Recurse?

Step 3: The Fix - Conditional Check

Real-World Usage

Building DeepReadonly<T> - Going Immutable

The Problem I Ran Into

Step 1: The Obvious Attempt

Step 2: Add Recursion + A Critical Catch

Where I Actually Use This

The infer Keyword — TypeScript's "Capture" Tool

The Analogy That Fixed It For Me

Peeking Under the Hood: ReturnType

The Real-World "Why": The Single Source of Truth

When I Find Myself Reaching For It

My Mental Shortcut

Template Literal Types - Type-Safe Strings

The Pattern

How It Works

Real-World Use Cases

The Polymorphic Pattern — Building a "Shape-Shifter"

The Problem

Building `DeepPartial<T>` - The Journey

Building `DeepReadonly<T>` - Going Immutable

The `infer` Keyword — TypeScript's "Capture" Tool

Peeking Under the Hood: `ReturnType`

Peeking at the Magic: `ComponentPropsWithRef`

1. `Partial<T>`

2. `Required<T>`

3. `Exclude<T, U>`

4. `Extract<T, U>`

5. `ReturnType<T>`

6. `Parameters<T>`

1. `Record<K, T>`

2. `NonNullable<T>`

3. `Pick<T, K>` & `Omit<T, K>`

`Pick<T, K>` - Extract only what you need

`Omit<T, K>` - Remove what you don't want