DEV Community: Parsa Jiravand

You use a setTimeout to trigger CSS entry animations. `@starting-style` makes it unnecessary.

Parsa Jiravand — Sat, 25 Jul 2026 08:13:01 +0000

Here is a pattern almost every frontend developer has written:

el.style.opacity = '0';
el.style.transform = 'translateY(8px)';
document.body.appendChild(el);

requestAnimationFrame(() => {
  requestAnimationFrame(() => {
    el.style.opacity = '1';
    el.style.transform = 'translateY(0)';
  });
});

Two requestAnimationFrame calls. Both are a hack. The first lets the browser commit the initial state to the render tree; the second triggers the transition. You may know the alternatives — a zero-millisecond setTimeout, a void el.offsetWidth reflow, or adding a class one tick after mount — but all of them are working around the same limitation.

CSS transition interpolates between a before state and an after state. When an element first appears in the DOM, there is no before state — the element simply did not exist. @starting-style was introduced to fill that gap.

What `@starting-style` does

@starting-style is an at-rule that lets you declare styles for an element before its first rendered frame. The browser uses those styles as the starting point for transitions when the element enters the page.

.notification {
  opacity: 1;
  transform: translateY(0);
  transition: opacity 0.3s ease, transform 0.3s ease;
}

@starting-style {
  .notification {
    opacity: 0;
    transform: translateY(12px);
  }
}

When .notification is inserted into the DOM, the browser reads @starting-style for the initial values and immediately transitions to the regular computed styles. The result is a smooth fade-and-slide-up — with zero JavaScript. No double rAF, no class toggle, no forced reflow.

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

Animating elements out of `display: none`

The second major use case is toggling visibility with display: none. Setting an element to display: block used to be incompatible with transitions: the element jumped from "not painted" to "painted" in a single frame, giving the transition engine nothing to work with.

With @starting-style and the new allow-discrete keyword, you can animate both the enter and exit:

.drawer {
  display: none;
  opacity: 0;
  transform: translateX(-16px);
  transition:
    opacity 0.25s ease,
    transform 0.25s ease,
    display 0.25s allow-discrete;
}

.drawer.open {
  display: block;
  opacity: 1;
  transform: translateX(0);
}

@starting-style {
  .drawer.open {
    opacity: 0;
    transform: translateX(-16px);
  }
}

allow-discrete tells the browser that display is being deliberately transitioned: on enter it switches to block immediately so the element is visible during the animation; on exit it holds block until the transition completes before switching to none. Combined with @starting-style for the enter side, you get matching enter and exit animations from purely declarative CSS.

With native `popover` and `<dialog>`

@starting-style pairs especially well with the Popover API and <dialog>, which toggle between top-layer states. There's one extra property to handle: overlay, which controls whether the element stays in the top layer while an exit animation runs.

[popover] {
  opacity: 0;
  transform: scale(0.95);
  transition:
    opacity 0.2s ease,
    transform 0.2s ease,
    display 0.2s allow-discrete,
    overlay 0.2s allow-discrete;
}

[popover]:popover-open {
  opacity: 1;
  transform: scale(1);
}

@starting-style {
  [popover]:popover-open {
    opacity: 0;
    transform: scale(0.95);
  }
}

Without transitioning overlay, the popover is pulled out of the top layer before the exit transition finishes — it disappears instantly. With allow-discrete on both display and overlay, the element stays rendered and on top until the animation completes, then the browser cleans it up. You get a polished open/close pair with no JavaScript involvement at all.

Browser support and graceful degradation

@starting-style shipped in Chrome 117 (September 2023), Firefox 129 (August 2024), and Safari 17.5 (May 2024). It has broadly available baseline support as of mid-2025.

For older browsers, the @starting-style block is silently ignored — elements appear without an entry animation rather than breaking. That is exactly the right degradation: the animation is an enhancement, not a requirement. You do not need a polyfill.

🧠 Test yourself

Think it clicked? Take the 6-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The takeaway

The double-rAF trick and the zero-millisecond setTimeout exist because CSS transitions need a "before" state, and there was no native way to provide one for elements entering the DOM. @starting-style is that native way. If your code applies a class one tick after mount, or toggles a data attribute to kick off an enter animation, look at whether @starting-style can replace it. The browser handles the timing correctly by definition; your JavaScript approximation might not.

Thanks for reading! Let's stay connected:

⭐ GitHub — follow me and star the projects: github.com/parsajiravand
📸 Instagram — frontend best practices, daily: @bestpractice___
💼 LinkedIn — linkedin.com/in/parsa-jiravand
✉️ Email (work & contract inquiries): bestpractice2026@gmail.com

You still write `finally { resource.close() }`. The `using` keyword does it automatically.

Parsa Jiravand — Fri, 24 Jul 2026 08:33:28 +0000

You've written this pattern — or something close to it — many times:

const timer = setTimeout(flush, 5000);
try {
  await doWork();
} finally {
  clearTimeout(timer);
}

The cleanup is real and necessary. But it's twelve lines away from the allocation, and every time the function grows — another early return, another throw path — you have to remember to extend the finally block. Miss one and you've leaked a timer.

TypeScript 5.2 (and TC39's Explicit Resource Management proposal) added a using declaration that ties cleanup directly to the variable binding. The scope exits → the resource disposes. No finally required.

What `using` does

using works like const with one difference: when the block it was declared in exits — normally, via early return, or via an exception — it calls [Symbol.dispose]() on the value automatically.

class ManagedTimer {
  #id: ReturnType<typeof setTimeout>;

  constructor(fn: () => void, ms: number) {
    this.#id = setTimeout(fn, ms);
  }

  [Symbol.dispose]() {
    clearTimeout(this.#id);
  }
}

async function doWork() {
  using _timer = new ManagedTimer(flush, 5000);
  await processItems();
  // clearTimeout is called here, regardless of whether
  // processItems() returned normally or threw
}

The cleanup is now written at the allocation site. Anyone reading the function sees the timer and its lifetime in the same line. No finally block to track, no hidden path that forgets to clean up.

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

Async teardown with `await using`

If cleanup is asynchronous — closing a database connection, flushing a write buffer, calling an HTTP endpoint — you need await using instead:

class DbConnection {
  async [Symbol.asyncDispose]() {
    await this.pool.end();
  }
}

async function runQuery(sql: string) {
  await using conn = await openConnection();
  return conn.execute(sql);
  // conn.pool.end() is awaited automatically when this returns
}

await using calls [Symbol.asyncDispose]() and awaits it before the surrounding async function resolves. The caller never sees a half-torn-down resource.

Making your own disposables

Any object with [Symbol.dispose]() (or [Symbol.asyncDispose]()) is a disposable. That includes objects you write yourself, but also wrappers you can add to things you don't own:

function managedListener<K extends keyof HTMLElementEventMap>(
  target: HTMLElement,
  type: K,
  handler: (e: HTMLElementEventMap[K]) => void
): Disposable {
  target.addEventListener(type, handler);
  return {
    [Symbol.dispose]() {
      target.removeEventListener(type, handler);
    },
  };
}

function trackHover(el: HTMLElement) {
  using _enter = managedListener(el, 'mouseenter', onEnter);
  using _leave = managedListener(el, 'mouseleave', onLeave);
  // both listeners are removed when this scope exits
}

Multiple using declarations in the same scope dispose in reverse order — last declared, first cleaned up — which mirrors how stack unwinding works and keeps teardown safe when resources depend on each other.

`DisposableStack` for dynamic resource groups

When the number of resources isn't known at compile time, DisposableStack (and its async counterpart AsyncDisposableStack) lets you register them at runtime:

async function processAll(paths: string[]) {
  await using stack = new AsyncDisposableStack();
  const handles = await Promise.all(
    paths.map(p => stack.use(openFile(p)))
  );
  await transformAll(handles);
  // every file handle is closed in reverse order here
}

stack.use(resource) returns the resource and registers it for disposal. When the stack itself disposes, everything registered to it disposes in reverse order. You get deterministic, ordered cleanup without writing a single finally.

TypeScript and browser support

TypeScript added using and await using in version 5.2 (August 2023). To get the types for Symbol.dispose, Symbol.asyncDispose, DisposableStack, and AsyncDisposableStack, add "ES2026" to the lib array in your tsconfig.json:

{
  "compilerOptions": {
    "lib": ["DOM", "ES2026"],
    "target": "ES2022"
  }
}

Note that lib controls which type definitions are available. The compiled output still targets whatever target is set to — TypeScript will emit try/finally for older targets, so the runtime behavior is correct even in environments that don't natively support using yet.

Natively, using shipped in Chrome 134 (March 2025), Firefox 134, and Safari 18.2. Node.js 22 supports it behind a flag; Node.js 24 enables it by default.

🧠 Test yourself

Think it clicked? Take the 6-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The takeaway

Search your codebase for finally { blocks. The ones that exist only to release a resource — clear a timeout, remove a listener, close a connection — are candidates for using. Each one can move its cleanup from a finally block to the line where the resource is allocated, making the lifetime visible at a glance and eliminating a whole class of cleanup bugs.

using doesn't replace try/catch for error handling. It replaces the finally that does nothing but clean up. That's a smaller scope, but it's the scope you write wrong the most often.

Thanks for reading! Let's stay connected:

⭐ GitHub — follow me and star the projects: github.com/parsajiravand
📸 Instagram — frontend best practices, daily: @bestpractice___
💼 LinkedIn — linkedin.com/in/parsa-jiravand
✉️ Email (work & contract inquiries): bestpractice2026@gmail.com

You've been doing Set math by hand. JavaScript finally shipped `.union()`, `.intersection()`, and friends.

Parsa Jiravand — Thu, 23 Jul 2026 08:37:01 +0000

You've written some version of this:

const intersection = new Set([...setA].filter(x => setB.has(x)));
const difference   = new Set([...setA].filter(x => !setB.has(x)));
const union        = new Set([...setA, ...setB]);

It works. It's also four lines of manual iteration for operations any set-theory textbook covers in a sentence. JavaScript's Set shipped in ES6 — ten years ago — but the methods that make sets actually useful didn't come with it.

ES2025 added them. All of them.

The seven new methods

Every new Set method takes another set-like object — a Set, a Map, or anything with a size property and a has method — and returns a new Set without modifying either input.

.union(other) — all elements from both sets:

const a = new Set([1, 2, 3]);
const b = new Set([3, 4, 5]);

a.union(b); // Set {1, 2, 3, 4, 5}

.intersection(other) — only elements present in both:

a.intersection(b); // Set {3}

.difference(other) — elements in this that are not in other:

a.difference(b); // Set {1, 2}
b.difference(a); // Set {4, 5}

.symmetricDifference(other) — elements in exactly one of the two sets:

a.symmetricDifference(b); // Set {1, 2, 4, 5}

These four cover the standard set algebra you reach for most often. The other three are boolean predicates:

.isSubsetOf(other) — true if every element of this is in other:

new Set([1, 2]).isSubsetOf(new Set([1, 2, 3])); // true
new Set([1, 4]).isSubsetOf(new Set([1, 2, 3])); // false

.isSupersetOf(other) — true if every element of other is in this:

new Set([1, 2, 3]).isSupersetOf(new Set([1, 2])); // true

.isDisjointFrom(other) — true if the sets share no elements at all:

new Set([1, 2]).isDisjointFrom(new Set([3, 4])); // true
new Set([1, 2]).isDisjointFrom(new Set([2, 3])); // false

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

A real-world example: permission diffing

The operations pay for themselves quickly when you're comparing sets of strings:

const currentPermissions = new Set(['read', 'write', 'admin']);
const requiredPermissions = new Set(['read', 'write', 'delete']);

const missing = requiredPermissions.difference(currentPermissions);
// Set {'delete'} — what the user needs but doesn't have

const hasAll = requiredPermissions.isSubsetOf(currentPermissions);
// false — deny access

Or computing which tags changed between two versions of a document:

const before = new Set(['react', 'typescript', 'css']);
const after  = new Set(['react', 'vue', 'css', 'tailwind']);

const added   = after.difference(before);      // Set {'vue', 'tailwind'}
const removed = before.difference(after);      // Set {'typescript'}
const stable  = before.intersection(after);    // Set {'react', 'css'}

Before, each of those lines was a three-liner. Now each is one method call that reads exactly like what it computes.

The "set-like" argument

Each method accepts any set-like object — not just Set instances. The spec defines set-like as any object with a numeric size property, a has(key) method, and a keys() method returning an iterator.

This means you can pass a Map as the argument and it works using the map's keys:

const activeUserIds = new Map([['u1', userA], ['u2', userB]]);
const bannedIds     = new Set(['u2', 'u3']);

bannedIds.intersection(activeUserIds); // Set {'u2'}

It also means you can build custom data structures that interoperate with the native methods without converting to a plain Set first — anything implementing the three-property contract is compatible.

TypeScript support

TypeScript added the full method signatures in version 5.5 under the ES2025 lib. If your tsconfig.json targets an earlier version, you'll see type errors. The fix is adding "ES2025" (or the more specific "ES2025.Collection") to your lib array:

{
  "compilerOptions": {
    "lib": ["DOM", "ES2025"]
  }
}

The algebra methods return Set<T> and the predicates return boolean. No type assertions or manual casting needed.

Browser support

All seven methods are Baseline 2025: Chrome 122, Firefox 127, Safari 17.4, Node.js 22. Any environment targeting browsers from the last year ships these with no polyfill and no build step.

If you need to support older targets, a shim is a few dozen lines — but every major browser in active use today already has them natively.

🧠 Test yourself

Think it clicked? Take the 6-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The takeaway

Search your codebase for filter(x => otherSet.has(x)) or new Set([...a, ...b]). Each one is a native Set method written by hand.

The new methods aren't just shorter — they're clearer. .difference() names the operation. A spread with a filter describes the implementation. When both are available, the one that names the operation wins: it reads faster, it refactors cleaner, and it signals intent to the next person in the file. The only reason to reach for the manual version now is a polyfill budget you almost certainly don't have.

Thanks for reading! Let's stay connected:

⭐ GitHub — follow me and star the projects: github.com/parsajiravand
📸 Instagram — frontend best practices, daily: @bestpractice___
💼 LinkedIn — linkedin.com/in/parsa-jiravand
✉️ Email (work & contract inquiries): bestpractice2026@gmail.com

You keep escaping the Promise constructor. `Promise.withResolvers` does it right.

Parsa Jiravand — Wed, 22 Jul 2026 08:35:51 +0000

Every JavaScript developer has written this at least once:

let resolve, reject;
const promise = new Promise((res, rej) => {
  resolve = res;
  reject = rej;
});

// Later…
eventBus.on('done', () => resolve(result));

You need to trigger the Promise from outside the constructor — from an event listener, a callback, or a message handler. So you capture resolve and reject by leaking them into the outer scope. It works. It also looks wrong every time you write it, because you're manually escaping a closure that wasn't designed to be escaped.

ES2024 added the right tool for this: Promise.withResolvers.

What `Promise.withResolvers` returns

Instead of constructing a Promise and escaping its callbacks, you call a static method that hands you all three pieces at once:

const { promise, resolve, reject } = Promise.withResolvers();

promise is a regular Promise. resolve and reject are its resolution functions, already sitting in your scope. No closure escape needed. The pattern that used to take four lines now takes one.

The old pattern and the new one behave identically — the same microtask timing, the same error propagation, the same .then/.catch interface. The difference is that the intent is now explicit: you're creating a deferred Promise on purpose, not as a workaround.

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

The event-to-Promise bridge

The clearest use case is wrapping event-based APIs in a Promise interface. Before:

function waitForOpen(socket) {
  let resolve, reject;
  const promise = new Promise((res, rej) => {
    resolve = res;
    reject = rej;
  });
  socket.addEventListener('open', () => resolve());
  socket.addEventListener('error', (e) => reject(e));
  return promise;
}

After:

function waitForOpen(socket) {
  const { promise, resolve, reject } = Promise.withResolvers();
  socket.addEventListener('open', () => resolve());
  socket.addEventListener('error', (e) => reject(e));
  return promise;
}

Same logic, much less ceremony. The function returns a Promise that resolves or rejects based on the socket's events — which is exactly what you'd read from the clean version. The old version made you parse around the escape boilerplate to get there.

Async queues and message passing

A place where deferred Promises appear repeatedly is async queues — structures where a consumer awaits the next item and a producer calls push later:

function createQueue() {
  const pending = [];
  let deferred = Promise.withResolvers();

  return {
    push(item) {
      pending.push(item);
      deferred.resolve();
      deferred = Promise.withResolvers();
    },

    async *[Symbol.asyncIterator]() {
      while (true) {
        await deferred.promise;
        while (pending.length) {
          yield pending.shift();
        }
      }
    },
  };
}

const queue = createQueue();

// Consumer
(async () => {
  for await (const item of queue) {
    console.log('received:', item);
  }
})();

// Producer (elsewhere)
queue.push('hello');
queue.push('world');

Each call to Promise.withResolvers() creates a fresh gate. The consumer waits on it; the producer resolves it when there's something to read. Without withResolvers, every one of those gates would need the escape boilerplate. With it, the queue logic reads straight through.

Controlled flushing: waiting for a batch

Another pattern: collecting items for a batch operation and resolving all waiters at once when the batch fires.

class Batcher {
  #items = [];
  #deferred = Promise.withResolvers();

  add(item) {
    this.#items.push(item);
    return this.#deferred.promise;
  }

  async flush() {
    const batch = this.#items.splice(0);
    const { resolve } = this.#deferred;
    this.#deferred = Promise.withResolvers();
    const results = await this.#processBatch(batch);
    resolve(results);
    return results;
  }
}

Callers await batcher.add(item) and get the result when the batch flushes — whether that's triggered by a timer, a size limit, or explicit user action. Each flush resets the gate cleanly with a single Promise.withResolvers() call.

When not to reach for it

Deferred Promises are a tool for specific situations, not a general replacement for the constructor form. If you control both the setup and the resolution — fetch, fs.readFile, any async API you're directly awaiting — use async/await or the Promise constructor directly. Deferred patterns are specifically for when setup and resolution happen in different execution contexts that can't share a callback cleanly.

One concrete anti-pattern: if you find yourself calling resolve synchronously inside the same function that created the deferred, you probably just wanted new Promise(res => res(value)) — which is Promise.resolve(value).

TypeScript support

TypeScript added Promise.withResolvers in version 5.4. The return type is typed correctly — PromiseWithResolvers<T> carries the type through:

const { promise, resolve, reject } = Promise.withResolvers<string>();

resolve('hello');       // ✅ string
resolve(42);            // ❌ type error

If you're on an older TS target, add "ES2024" to lib in your tsconfig.json.

Browser support

Promise.withResolvers is Baseline 2024: Chrome 119, Firefox 121, Safari 17.4, Node.js 22. If you're targeting modern environments, it's available with no polyfill. For older targets, the old escape pattern remains correct — withResolvers is syntax sugar for something you can always write by hand.

🧠 Test yourself

Think it clicked? Take the 6-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The takeaway

Search your codebase for the pattern let resolve or let reject followed by a new Promise. Every one of those is a deferred Promise written the hard way. Promise.withResolvers() names the pattern, eliminates the escape boilerplate, and makes the intent readable at a glance. The result is the same; the code is cleaner by a visible margin.

Thanks for reading! Let's stay connected:

⭐ GitHub — follow me and star the projects: github.com/parsajiravand
📸 Instagram — frontend best practices, daily: @bestpractice___
💼 LinkedIn — linkedin.com/in/parsa-jiravand
✉️ Email (work & contract inquiries): bestpractice2026@gmail.com

You're rethrowing errors and losing context. `Error.cause` fixes that.

Parsa Jiravand — Tue, 21 Jul 2026 08:36:01 +0000

Error handling has a quiet problem. You catch an error deep in a call stack, wrap it in something more descriptive, and rethrow. The caller gets a meaningful message — but the original error, with its stack trace and details, is gone.

async function loadUser(id) {
  try {
    const res = await fetch(`/api/users/${id}`);
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    return await res.json();
  } catch (err) {
    throw new Error(`Failed to load user ${id}`); // original err swallowed
  }
}

Your logs now say Failed to load user 42 and nothing else. Was it a network timeout? A 403? A JSON parse error? You don't know unless you explicitly log before rethrowing — which most people remember only after the third unexplained production incident.

ES2022 added the fix: the cause option on Error.

How `Error.cause` works

Every Error constructor accepts an optional second argument: an options object. Set cause to the original error and it's preserved on the new error:

async function loadUser(id) {
  try {
    const res = await fetch(`/api/users/${id}`);
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    return await res.json();
  } catch (err) {
    throw new Error(`Failed to load user ${id}`, { cause: err });
  }
}

Now the new error carries the original as err.cause. When the caller catches it, both levels are available:

try {
  await loadUser(42);
} catch (err) {
  console.error(err.message);       // "Failed to load user 42"
  console.error(err.cause.message); // "HTTP 403"
  console.error(err.cause);         // the original Error with its full stack trace
}

The original error isn't gone — it's attached. One property to read when you need it, invisible when you don't.

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

Error chains instead of error strings

The old workaround was to concatenate messages:

throw new Error(`Failed to load user ${id}: ${err.message}`);

This preserves the message text — but only the text. The stack trace of the original error disappears. The error type disappears. If the original error had a cause of its own, that disappears too.

With Error.cause, you get a chain, not a flattened string:

// Higher up the stack
try {
  await initDashboard();
} catch (err) {
  console.error(err.message);             // "Dashboard init failed"
  console.error(err.cause.message);       // "Failed to load user 42"
  console.error(err.cause.cause.message); // "HTTP 403"
}

Every layer adds context. None of them destroy what came before.

A real-world pattern: the service layer

The clearest use case is a service layer wrapping raw API calls:

class UserService {
  async getUser(id) {
    try {
      const raw = await this.api.get(`/users/${id}`);
      return User.from(raw);
    } catch (err) {
      throw new Error(`UserService.getUser(${id}) failed`, { cause: err });
    }
  }
}

The caller gets a domain error (UserService.getUser(42) failed) without losing the infrastructure detail (HTTP 403, ECONNREFUSED, SyntaxError: Unexpected token). A logging layer can walk the .cause chain to emit structured logs at each level. Error monitoring tools that understand cause chains — Sentry does — can render the full tree as a linked sequence rather than a flattened string.

TypeScript support

TypeScript added the ErrorOptions type in 4.6. The cause field is typed as unknown, which is correct — any value can be a cause, not just Error instances:

throw new Error('Operation failed', { cause: err });
// err.cause is typed as unknown — narrow it before using

if (err.cause instanceof Error) {
  console.error(err.cause.message); // ✅ safe
}

Custom error classes work the same way — pass options through to super and the base Error constructor populates this.cause automatically:

class ApiError extends Error {
  constructor(message: string, options?: ErrorOptions) {
    super(message, options);
    this.name = 'ApiError';
  }
}

throw new ApiError('Request failed', { cause: originalError });

`cause` doesn't have to be an Error

cause accepts any value. If what went wrong was a failed validation, a non-Error rejected promise, or a raw HTTP response object, attach it directly:

throw new Error('Invalid configuration', {
  cause: { field: 'timeout', received: -1, expected: '>0' },
});

err.cause holds the original object — not a stringified version of it. That's more useful than trying to serialize context into a message string and more structured than console-logging separately before rethrowing.

Browser support

Error options including cause are Baseline 2022: Chrome 93, Firefox 91, Safari 15.4, Node.js 16.9. Every actively maintained browser and runtime ships it. There is nothing to install and nothing to polyfill; the only thing to change is the habit.

🧠 Test yourself

Think it clicked? Take the 6-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The takeaway

Search your codebase for catch (err) { throw new Error( and look at each one. Where the catch clause doesn't forward err, it's swallowing context someone will want the next time that error appears in production.

Pass { cause: err } as the second argument to Error() and the original error stops disappearing. The message is what you put in the error. The cause is what actually went wrong underneath. They belong in the same object.

Thanks for reading! Let's stay connected:

⭐ GitHub — follow me and star the projects: github.com/parsajiravand
📸 Instagram — frontend best practices, daily: @bestpractice___
💼 LinkedIn — linkedin.com/in/parsa-jiravand
✉️ Email (work & contract inquiries): bestpractice2026@gmail.com

TypeScript Generics: The Complete Guide (with Cheat Sheet)

Parsa Jiravand — Mon, 20 Jul 2026 09:23:23 +0000

You write a function that works on numbers. Then you need the same function for strings. You copy-paste it and change the type annotation. Then arrays. Then objects. Now you have four functions with identical bodies and different type signatures — or you gave up and typed everything any, and the compiler stopped helping you at the one place you needed it most: the boundary between what you pass in and what you get back.

What you'll learn

By the end of this guide you'll be able to:

Write generic functions that preserve the exact type of their input in their output, instead of widening it to any or unknown
Constrain a type parameter with extends so the compiler enforces a shape without collapsing to one concrete type
Give a type parameter a sensible default, the way you'd default a function argument
Read and write generic interfaces, types, and classes with more than one type parameter
Diagnose the most common generic inference failures instead of reaching for any to silence them

Who this is for: you've written TypeScript with interfaces and function signatures, and you've seen <T> in library code, but you want the model that makes it predictable instead of memorized syntax.

Why generics exist
The mental model
Stage 1: your first generic function
Stage 2: generic interfaces and types
Stage 3: constraining a type parameter with extends
Stage 4: default type parameters
Stage 5: multiple type parameters and generic classes
Edge cases and gotchas
Best practices
FAQ
Cheat sheet
Key takeaways

Why generics exist

Here's the naive fix for "I need this function to work on more than one type" — widen the parameter to any:

function firstElement(arr: any): any {
  return arr[0];
}

const n = firstElement([1, 2, 3]);      // typed as `any` — no autocomplete, no error checking
const s = firstElement(["a", "b"]);     // also `any` — TypeScript has no idea it's a string
n.toUpperCase();                        // compiles fine, crashes at runtime: not a string

The function works at runtime for both calls. But the moment you use the result, TypeScript has nothing to say — any erases the connection between what went in and what came out. You've traded a compile-time error for a runtime crash, which is the one trade TypeScript exists to prevent.

The alternative most people try next is copy-pasting one function per type:

function firstNumber(arr: number[]): number { return arr[0]; }
function firstString(arr: string[]): string { return arr[0]; }
// ...one more function for every type you ever call this with

This is type-safe, but it doesn't scale — you're maintaining N identical function bodies, and a bug fix means updating all of them. Generics solve exactly this: one function body, and a type that adapts to whatever you call it with, while the compiler still checks that the relationship holds.

The mental model: a type parameter is a function argument for types

The mental model: a generic <T> is a parameter, exactly like a function parameter — except instead of a value, you're passing in a type, and the compiler substitutes it everywhere T appears and checks that everything stays consistent.

Compare the two side by side:

// a regular function: `x` is a placeholder for a VALUE, filled in at the call site
function double(x: number): number {
  return x * 2;
}
double(5); // x = 5

// a generic function: `T` is a placeholder for a TYPE, filled in at the call site
function identity<T>(x: T): T {
  return x;
}
identity(5);      // T = number
identity("hi");   // T = string

double's parameter list says "give me a number, I'll give you a number." identity's type parameter list says "give me some type T, and I promise to give you back that same T" — it's a contract about the shape of the relationship, not about one fixed type. TypeScript infers T from the argument you actually pass, the same way it infers the type of a variable from its initializer — you rarely write identity<number>(5) explicitly; the compiler figures out T = number on its own.

That's the whole idea. Everything below is this one substitution rule, applied to interfaces, constraints, defaults, and classes.

Stage 1: your first generic function

Fix the firstElement function from earlier with a type parameter instead of any:

function firstElement<T>(arr: T[]): T | undefined {
  return arr[0];
}

const n = firstElement([1, 2, 3]);    // n: number | undefined
const s = firstElement(["a", "b"]);   // s: string | undefined
n?.toFixed(2);                        // ✅ compiler knows n might be a number
s?.toUpperCase();                     // ✅ compiler knows s might be a string

Key concept: T is inferred once, from the argument, and then reused for the return type. The function body never mentions number or string — it stays generic, but every call site gets a fully concrete, checked type back.

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

The T | undefined return type matters too: an empty array is a valid T[], so the function is honest that there might be nothing at index 0. This is a case where any would have silently hidden a real edge case that T | undefined forces you to handle.

Generic functions can also take more than the type parameter implies. A map-style helper needs a second, ordinary parameter — a callback — that also mentions T:

function mapArray<T, U>(arr: T[], fn: (item: T) => U): U[] {
  return arr.map(fn);
}

const lengths = mapArray(["a", "bb", "ccc"], (s) => s.length); // lengths: number[]

Here T is inferred from arr (string) and U is inferred from what fn returns (number) — two independent type parameters, each pinned down by a different argument.

Stage 2: generic interfaces and types

The same substitution rule applies to interface and type, not just functions. A generic interface is a shape with a type-level blank to fill in:

interface Box<T> {
  value: T;
}

const numberBox: Box<number> = { value: 42 };
const stringBox: Box<string> = { value: "hello" };
// const bad: Box<number> = { value: "hello" }; // ❌ string is not assignable to number

Box<T> isn't a type by itself — it's a template for a type. Box<number> and Box<string> are the actual types, produced by substituting T. This is the exact same mechanism as Array<T> (the type behind T[]), Promise<T>, and Map<K, V> from the standard library — you've been using generics since your first Promise<void>, you just hadn't named the mechanism yet.

Generic type aliases work identically and are common for API response shapes:

type ApiResponse<T> = {
  data: T;
  error: string | null;
};

async function getUser(id: string): Promise<ApiResponse<User>> {
  // ...
}

Every endpoint reuses one ApiResponse<T> shape instead of a hand-written UserResponse, PostResponse, OrderResponse trio that all say the same thing with different names.

Stage 3: constraining a type parameter with extends

Unconstrained, T could be anything — which means you can't assume it has any properties at all:

function getLength<T>(item: T): number {
  return item.length; // ❌ Property 'length' does not exist on type 'T'
}

The compiler is right to reject this: nothing says T has a .length. The fix is a constraint — extends here doesn't mean "inherits from," it means "must be assignable to":

interface HasLength {
  length: number;
}

function getLength<T extends HasLength>(item: T): number {
  return item.length; // ✅ every T that reaches this line is guaranteed to have `.length`
}

getLength("hello");        // ✅ strings have .length
getLength([1, 2, 3]);      // ✅ arrays have .length
getLength({ length: 10 }); // ✅ any object shape with a length field
getLength(42);              // ❌ number has no .length

Key concept: T extends HasLength narrows which types are legal, not what T collapses to. T is still inferred per call — a string, an array, or a custom object — the constraint only guarantees the one property you need.

A very common constraint pattern uses keyof to guarantee a key actually exists on an object, which is what makes a type-safe getProperty helper possible:

function getProperty<T, K extends keyof T>(obj: T, key: K): T[K] {
  return obj[key];
}

const user = { name: "Ada", age: 36 };
getProperty(user, "name");   // ✅ inferred as string
getProperty(user, "email");  // ❌ "email" is not a key of { name: string; age: number }

K extends keyof T reads as "K must be one of T's actual property names." Once that holds, T[K] — an indexed access type — gives you the precise type of that property, so getProperty(user, "age") returns number, not some generic unknown.

Stage 4: default type parameters

A type parameter can have a default, exactly like a function parameter can have a default value — used when the caller doesn't supply one:

interface FetchOptions<TResponse = unknown> {
  url: string;
  parse?: (raw: string) => TResponse;
}

const raw: FetchOptions = { url: "/ping" };                 // TResponse defaults to unknown
const typed: FetchOptions<{ ok: boolean }> = {               // explicit, overrides the default
  url: "/health",
  parse: (raw) => JSON.parse(raw),
};

Defaults matter most on widely-used generic types where most callers don't care about every parameter — a state-management or component-library type might have four type parameters with sensible defaults so 90% of call sites only ever write the one that matters to them, and the rest fall back silently.

Stage 5: multiple type parameters and generic classes

Nothing restricts you to one T. Multiple type parameters are common wherever there's a key/value or input/output relationship:

function zip<A, B>(a: A[], b: B[]): [A, B][] {
  return a.map((item, i) => [item, b[i]]);
}

zip([1, 2], ["a", "b"]); // [number, string][] — inferred as [[1, "a"], [2, "b"]]

Classes take type parameters the same way functions do — on the class itself, available to every method and property inside:

class Stack<T> {
  private items: T[] = [];

  push(item: T): void {
    this.items.push(item);
  }

  pop(): T | undefined {
    return this.items.pop();
  }

  get size(): number {
    return this.items.length;
  }
}

const numbers = new Stack<number>();
numbers.push(1);
numbers.push(2);
numbers.pop(); // number | undefined

const strings = new Stack<string>();
strings.push("a");
// strings.push(1); // ❌ number is not assignable to string

T is fixed once, at new Stack<number>(), and every method on that instance uses that same T for the rest of its life — push and pop stay in sync automatically, without repeating the type anywhere else in the class body.

Edge cases and gotchas

Type erasure at runtime. Generics are a compile-time-only construct — they're erased entirely from the emitted JavaScript. You cannot check typeof T or branch on T at runtime; if you need runtime knowledge of the type, you must pass it explicitly as a value (a constructor, a discriminant field, or a plain string tag), because by the time your code runs, T no longer exists.
Inference can fail on object literals with contextual typing. identity({ name: "Ada" }) infers T as { name: string }, which is often what you want, but if you need a wider inferred literal type (e.g. keeping a string as a specific literal rather than widening to string), you'll need as const on the argument, not a change to the generic itself.
Arrow functions with generics need care in .tsx files. const identity = <T>(x: T) => x; can be parsed as a JSX opening tag inside a .tsx file. The common workaround is a trailing comma — <T,>(x: T) => x — or naming a constraint explicitly, <T extends unknown>(x: T) => x.
Conditional types distribute over unions unless you stop them. type ToArray<T> = T extends any ? T[] : never; applied to string | number produces string[] | number[], not (string | number)[], because a naked type parameter in a conditional type distributes across each union member individually. Wrapping both sides in a tuple ([T] extends [any] ? ...) disables that distribution when you don't want it.
A constraint is a floor, not the resolved type. function f<T extends { id: string }>(x: T) still infers the caller's full type for T (every extra property survives), not just { id: string } — the constraint only restricts which types are legal, it doesn't narrow what gets stored in T.

Best practices: when (not) to reach for generics

Reach for a generic when a function or type's inputs and outputs are related and that relationship needs to survive into the caller's code — a firstElement<T> that returns the same T it received, a Box<T> that wraps any payload, an ApiResponse<T> reused across every endpoint.

Don't reach for a generic when a union type says what you mean more simply. If a parameter only ever needs to be "light" | "dark", write that union — a <T extends "light" | "dark"> generic adds ceremony without adding safety.

Don't reach for a generic to avoid writing unknown. If a value's type genuinely isn't knowable until you inspect it at runtime (parsed JSON, a catch block's error), the honest type is unknown plus a runtime check — not a type parameter with no way to constrain it, and not any, which is how you end up back at the firstElement bug from the top of this article. TypeScript's own satisfies operator solves a related but different problem — keeping a literal's narrow type while still validating it against a shape — worth knowing alongside generics, not instead of them.

Don't over-parameterize. A function with four type parameters, three of them defaulted and never varied at any call site in your codebase, is a sign the abstraction arrived before the second real use case did. Write the concrete version first; generalize when a second caller actually needs a different type.

FAQ

What is a generic in TypeScript?

A generic is a type parameter — a placeholder for a type, written in angle brackets like <T> — that lets a function, interface, type, or class work with any type while the compiler still tracks and checks that type through every use, instead of collapsing everything to any.

Is `T extends SomeType` the same as class inheritance?

No. In a generic constraint, extends means "must be assignable to" or "must have at least this shape" — it restricts which types are legal for T, not a class hierarchy. T extends { id: string } accepts any type with an id: string property, not just subclasses of some { id: string } class.

Can I use a default value for a generic type parameter?

Yes — interface Box<T = unknown> gives T a default the same way a function parameter can have one. Callers that don't specify a type argument get the default; callers that do (Box<number>) override it.

Is `any` the same as a generic?

No, and this is the most common confusion. any disables type checking entirely for that value — TypeScript stops tracking it. A generic T keeps type checking fully active; it just defers which type until the call site, and enforces that the same T is used consistently everywhere it appears.

Do generic types exist at runtime?

No. TypeScript's type system, including all generics, is erased during compilation — there is no T in the emitted JavaScript, and you cannot inspect it with typeof or instanceof at runtime. Anything you need to know while the program is running must be represented as an actual runtime value, not just a type parameter.

Cheat sheet

Task	Syntax	Notes
Generic function	`function f<T>(x: T): T`	`T` inferred from the argument
Generic interface/type	`interface Box<T> { value: T }`	Instantiate as `Box<number>`
Multiple type parameters	`function zip<A, B>(a: A[], b: B[])`	Each inferred independently
Constrain a type parameter	`<T extends HasLength>`	"Must be assignable to," not inheritance
Require a real key of an object	`<T, K extends keyof T>`	Pairs with indexed access: `T[K]`
Default type parameter	`<T = unknown>`	Used when the caller omits a type argument
Generic class	`class Stack<T> { push(item: T): void }`	`T` fixed once, at `new Stack<number>()`
Explicit type argument (rare)	`identity<string>("hi")`	Usually unnecessary — inference handles it

// The whole pattern, copy-paste ready
interface ApiResponse<TData = unknown> {
  data: TData;
  error: string | null;
}

function firstMatching<T, K extends keyof T>(
  items: T[],
  key: K,
  value: T[K]
): T | undefined {
  return items.find((item) => item[key] === value);
}

class Cache<T> {
  private store = new Map<string, T>();
  set(key: string, value: T): void { this.store.set(key, value); }
  get(key: string): T | undefined { return this.store.get(key); }
}

// usage — every T flows through, checked, with no `any` anywhere
const cache = new Cache<ApiResponse<{ id: string }>>();

🧠 Test yourself

Think it clicked? Take the 7-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

Key takeaways

A type parameter is a function argument for types — the compiler substitutes it at the call site and checks the relationship stays consistent, the same way it checks a value argument.
extends in a generic constraint means "must be assignable to," not class inheritance — it narrows which types are legal without collapsing T to one fixed type.
Reach for a generic when an input and an output (or two inputs) are related and that relationship must survive into the caller's code; reach for a plain union or unknown when it doesn't.
Generics are erased at compile time — there's no T left at runtime, so runtime type decisions need an actual value, not a type parameter.
any and a generic solve opposite problems: any turns off checking, a generic keeps it on while deferring which type.

You started this article maintaining four near-identical functions, one per type, or one function typed any that quietly let a string crash on .toUpperCase(). Now you have the one mechanism — a type parameter, substituted and checked at every call site — that replaces both: a single firstElement<T>, a single Cache<T>, a single ApiResponse<T>, each one exactly as safe as if you'd hand-written it for every type you'll ever call it with. Where's the first place in your own codebase you'll delete a copy-pasted function and replace it with one generic? Tell me in the comments.

Your scroll listener fires on every pixel. `IntersectionObserver` fires when visibility actually changes.

Parsa Jiravand — Sun, 19 Jul 2026 08:25:59 +0000

Here is a pattern I still see in real codebases:

window.addEventListener('scroll', () => {
  const rect = element.getBoundingClientRect();
  if (rect.top < window.innerHeight && rect.bottom >= 0) {
    loadImage(element);
  }
});

It works. It's also firing on every pixel of scroll movement — potentially 60 callbacks per second on a smooth display — and each one calls getBoundingClientRect(), which forces a synchronous layout recalculation. You probably added throttling or requestAnimationFrame wrapping to soften the blow. You're still doing layout work on the main thread to answer a question the browser already knows the answer to.

IntersectionObserver has been baseline since 2019. It's still underused.

What it does

IntersectionObserver watches one or more elements and fires a callback only when their visibility status changes — entering the viewport, leaving it, or crossing a fraction threshold you specify. The geometry calculations happen off the main thread; you get called when something meaningful happens.

const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      console.log(entry.target, 'entered the viewport');
    }
  });
});

observer.observe(document.querySelector('.card'));

entries is an array of IntersectionObserverEntry objects — one per observed element that changed state in this tick. entry.isIntersecting is true when the element entered, false when it left.

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

Lazy loading an image

The classic use case. No scroll event, no position math:

const lazyImages = document.querySelectorAll('img[data-src]');

const imageObserver = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (!entry.isIntersecting) return;

    const img = entry.target;
    img.src = img.dataset.src;
    imageObserver.unobserve(img); // done watching this one
  });
});

lazyImages.forEach(img => imageObserver.observe(img));

The observer fires once when each image enters the viewport. After setting src, unobserve drops the element from the watch list. No cleanup loop, no residual listener, no memory leak.

`threshold` and `rootMargin`

Two options control exactly when the callback fires.

threshold is a number between 0 and 1 — the fraction of the element that must be visible. The default is 0, which fires the moment a single pixel enters the viewport. threshold: 1 waits until the element is fully visible. Pass an array to fire at multiple milestones:

const observer = new IntersectionObserver(callback, {
  threshold: [0, 0.25, 0.5, 0.75, 1],
});

entry.intersectionRatio tells you the actual fraction at the moment of the callback — useful for video autoplay, progressive reveal animations, or impression-depth analytics.

rootMargin works like a CSS margin around the viewport boundary, shifting where "visible" begins:

const observer = new IntersectionObserver(callback, {
  rootMargin: '0px 0px 300px 0px', // fire 300px before entering from the bottom
});

This is the correct tool for preloading. Trigger the network request 300px before the element reaches the viewport, so it's ready when the user gets there — without any manual distance math.

Analytics impression tracking

Knowing whether a user actually saw a piece of content, versus just scrolling past it, is a common product requirement. With a scroll listener you're sampling at intervals and accepting inaccuracy. With IntersectionObserver:

const impressionObserver = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (!entry.isIntersecting) return;
    analytics.track('impression', {
      id: entry.target.dataset.id,
      ratio: entry.intersectionRatio,
    });
    impressionObserver.unobserve(entry.target);
  });
}, { threshold: 0.5 }); // at least half the element must be visible

document.querySelectorAll('[data-track]').forEach(el => impressionObserver.observe(el));

The threshold: 0.5 option means a fast scroll past an element doesn't count — the user had to slow down enough for half of it to enter view. One observer, zero scroll event listeners, accurate data.

Cleanup in components

In React, Vue, or any component that mounts and unmounts, disconnect the observer on teardown:

useEffect(() => {
  const observer = new IntersectionObserver(callback);
  observer.observe(ref.current);

  return () => observer.disconnect(); // stops watching all elements
}, []);

disconnect() removes all observed elements at once. If you have a single long-lived observer watching multiple elements and only want to stop tracking one, unobserve(element) does that without affecting the rest.

🧠 Test yourself

Think it clicked? Take the 6-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The takeaway

IntersectionObserver answers the question "is this element visible?" without running on every scroll tick. The main thread is not involved — the browser handles the geometry internally and calls your callback only when the answer changes.

Search your codebase for scroll event listeners that contain getBoundingClientRect. Every one of them is a candidate for replacement. The handler runs less often, the layout thrash disappears, and the intent is clearer in the code: you're watching for visibility, and the observer is the right name for that.

Thanks for reading! Let's stay connected:

⭐ GitHub — follow me and star the projects: github.com/parsajiravand
📸 Instagram — frontend best practices, daily: @bestpractice___
💼 LinkedIn — linkedin.com/in/parsa-jiravand
✉️ Email (work & contract inquiries): bestpractice2026@gmail.com

You're using Floating UI to position your tooltip. The browser does it natively now.

Parsa Jiravand — Sat, 18 Jul 2026 07:59:41 +0000

Here is the code you have written, or something close to it, for every tooltip on every project:

import { computePosition, flip, shift, offset } from '@floating-ui/dom';

const { x, y } = await computePosition(button, tooltip, {
  placement: 'top',
  middleware: [offset(8), flip(), shift({ padding: 8 })],
});

Object.assign(tooltip.style, {
  left: `${x}px`,
  top: `${y}px`,
});

Then you wire it to a ResizeObserver so it recomputes when the button moves. Then a scroll listener for the same reason. Then you discover the tooltip clips inside an overflow: hidden parent and spend an afternoon understanding stacking contexts. The library is excellent — it handles real complexity. But the core problem it's solving — "position this element relative to that element, and keep it there" — is something the browser should have always owned.

As of 2026, it does — in every major engine.

The anchor model

CSS Anchor Positioning works in two steps: an element declares itself an anchor, then a floating element positions itself relative to it.

The anchor declares its name using a custom property (dashed-ident, same syntax as CSS variables):

.trigger-button {
  anchor-name: --my-tooltip-anchor;
}

The floating element links to it and uses the anchor() function to express where it should sit:

.tooltip {
  position: absolute;
  position-anchor: --my-tooltip-anchor;
  bottom: anchor(top);        /* align my bottom edge to anchor's top edge */
  left: anchor(center);       /* align my left edge to anchor's horizontal center */
  transform: translateX(-50%);
  margin-bottom: 8px;
}

The anchor() function is the engine. Its argument names which edge or midpoint of the anchor to reference: top, bottom, left, right, center, start, end. Those values are then used in standard inset properties — top, bottom, left, right, inset-inline-start, etc.

No JavaScript. No event listeners. The browser computes the anchor's position in the layout, resolves the floating element's insets against it, and keeps both in sync through reflows, resizes, and scrolls.

`position-area` for common placements

For the eight standard compass placements, there is a higher-level shorthand: position-area. It describes where the floating element lands relative to a 3×3 grid centered on the anchor:

.tooltip {
  position: absolute;
  position-anchor: --my-tooltip-anchor;
  position-area: top center;   /* above, horizontally centered */
  margin-bottom: 8px;
}

The grid vocabulary: top, center, bottom on the block axis; left, center, right (or the writing-mode-aware start, center, end) on the inline axis. Combine them to get any of the eight placements:

position-area: bottom right;   /* below and to the right */
position-area: top span-all;   /* above, stretching the full width of the anchor */
position-area: inline-start;   /* to the inline-start side (left in LTR) */

Use position-area for standard placements. Use anchor() directly when you need precise edge-to-edge control — for example, a dropdown that should align its left edge exactly with the anchor's left edge rather than centering.

Viewport overflow: `position-try-fallbacks`

The main reason you installed flip() and shift() middleware is viewport overflow: the tooltip was about to render off-screen, so the library flips it to the other side. CSS Anchor Positioning handles this natively with position-try-fallbacks:

.tooltip {
  position: absolute;
  position-anchor: --my-tooltip-anchor;
  position-area: top center;
  margin-bottom: 8px;

  position-try-fallbacks: bottom center, left center, right center;
}

The browser tries top center first. If the tooltip overflows the viewport in that position, it tries bottom center. If that overflows, it tries left center, then right center. The first placement that fits without overflow wins.

For the common case of just flipping across one axis, there are keyword shorthands:

position-try-fallbacks: flip-block, flip-inline;

flip-block means "try the opposite block edge" — if you specified top, try bottom. flip-inline means "try the opposite inline side." You can combine them: flip-block flip-inline tries the diagonally opposite placement.

This replaces the flip() and shift() middleware for the common use cases without any JavaScript.

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

What you still need a library for

CSS Anchor Positioning handles positioning and overflow. It does not handle every case.

The position-try-fallbacks detection is binary: either the element fits at a given placement or it doesn't. It does not compute how much space is available at each candidate and pick the largest. If you need "prefer below, but only if there are at least 200px of vertical clearance," you still need JavaScript.

Containment is another gap. If your floating element is inside an overflow: hidden parent — a scroll container, a card with clipping — it will clip there just like any other positioned element. The fix is to render the floating element in the top layer, which the Popover API handles. Combining popover="manual" with anchor positioning is the full modern stack: the popover attribute gets you out of the stacking context, anchor positioning places you correctly relative to the trigger.

Arrow indicators — the triangle that connects the tooltip to the trigger — are not automatic. You can compute the arrow position manually using anchor() values in a ::before pseudo-element, but it takes a few extra lines and isn't as polished as a library's arrow plugin out of the box.

Browser support

CSS Anchor Positioning is Baseline 2026: Chrome/Edge 125 (2024), Safari 26 (2025), and Firefox 147 (early 2026) — Firefox was the last engine to ship it, which is what tipped the feature into Baseline. It's now supported unflagged in every current browser. No flag, no polyfill, no build step.

🧠 Test yourself

Think it clicked? Take the 8-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The takeaway

Floating UI is an excellent library — but most of what it does at the positioning layer is the browser's job. For the common cases — tooltips, dropdowns, label overlays, context menus — anchor-name and position-anchor replace the installation entirely. position-area replaces the placement config. position-try-fallbacks replaces flip() and shift().

The pattern is the same one you have seen with the Popover API and scroll-driven animations: the browser absorbed the use case that a library existed to fill. You do not have to stop using Floating UI immediately. But the next tooltip you build, try starting with two CSS properties. The library is an escape hatch for the complex cases, not the baseline anymore.

Thanks for reading! Let's stay connected:

⭐ GitHub — follow me and star the projects: github.com/parsajiravand
📸 Instagram — frontend best practices, daily: @bestpractice___
💼 LinkedIn — linkedin.com/in/parsa-jiravand
✉️ Email (work & contract inquiries): bestpractice2026@gmail.com

Your `margin-left` doesn't exist in Arabic. CSS logical properties fix that.

Parsa Jiravand — Fri, 17 Jul 2026 08:18:04 +0000

Here is a layout assumption you have probably made without thinking about it.

A sidebar sits to the left of the content with margin-right: 1.5rem pushing the content away. A button has padding-left: 1rem so the label doesn't crowd its edge. A sticky header uses left: 0 to pin to the viewport. A nav indicator uses border-left: 3px solid.

All of that is correct in English, French, and German. In Arabic, Hebrew, or Persian — where text flows right-to-left — every one of those values is wrong. The sidebar should sit to the right. The button's breathing room belongs on the right edge. The sticky element pins to the right. The nav indicator appears on the right.

The standard patch is a [dir="rtl"] block that mirrors every physical property for right-to-left documents. You maintain two copies of every layout rule. They drift apart. They get missed.

CSS logical properties solve this at the property level.

The two axes

Physical CSS maps to the viewport: top, right, bottom, left. Logical CSS maps to the writing mode:

Inline axis — the direction text flows. Left-to-right in English; right-to-left in Arabic.
Block axis — the direction blocks stack. Top-to-bottom in most scripts.

Logical properties use inline and block in place of left/right/top/bottom. The browser resolves them to the correct physical direction based on the element's computed writing-mode and direction.

The main properties

Margins and padding:

/* Physical */
margin-left: 1rem;
padding-top: 0.5rem;

/* Logical */
margin-inline-start: 1rem;   /* left in LTR, right in RTL */
padding-block-start: 0.5rem; /* top in horizontal writing */

Shorthand versions collapse both sides at once:

margin-inline: 1rem;      /* inline-start AND inline-end */
padding-block: 0.5rem;    /* block-start AND block-end */
margin-block: 1.5rem 0;   /* block-start block-end */

Positioning:

/* Physical */
position: sticky;
left: 0;
top: 1rem;

/* Logical */
position: sticky;
inset-inline-start: 0;   /* left in LTR, right in RTL */
inset-block-start: 1rem; /* top in horizontal writing */

The four-value inset shorthand covers all sides: inset: 0 is equivalent to top: 0; right: 0; bottom: 0; left: 0.

Borders:

/* Physical — a left-side accent border */
border-left: 3px solid var(--accent);

/* Logical */
border-inline-start: 3px solid var(--accent);

Size:

/* Physical */
width: 100%;
height: 2rem;

/* Logical */
inline-size: 100%;  /* width in horizontal writing */
block-size: 2rem;   /* height in horizontal writing */

Text alignment:

/* Always aligns to the physical left edge */
text-align: left;

/* Aligns to the start of the inline axis */
text-align: start;

text-align: start is the most frequently missed change. In an English UI the two properties are identical — but when dir="rtl" is set on the <html> element, start aligns to the right automatically, while left stays physically left regardless of reading direction.

The before-and-after

A sidebar layout that supports both LTR and RTL, no override block needed:

/* Before — requires a full RTL mirror */
.sidebar {
  float: left;
  margin-right: 1.5rem;
  padding-left: 1rem;
  border-right: 1px solid var(--border);
}

[dir="rtl"] .sidebar {
  float: right;
  margin-right: 0;
  margin-left: 1.5rem;
  padding-left: 0;
  padding-right: 1rem;
  border-right: none;
  border-left: 1px solid var(--border);
}

/* After — one rule, both directions */
.sidebar {
  float: inline-start;
  margin-inline-end: 1.5rem;
  padding-inline-start: 1rem;
  border-inline-end: 1px solid var(--border);
}

The logical version is shorter, has no duplicate block, and flips automatically when dir="rtl" is set on <html>. The browser does the math; you don't maintain the mirror.

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

When to start using logical properties

If your app supports or may ever support RTL languages, audit your layout CSS. Common candidates are easy to spot: margins and paddings that describe spacing relative to "the start of the content," text-align: left, left: 0 on sticky or fixed elements, and border-left/border-right accent styles.

If your app is English-only today, the case is still real. Apps grow. Retrofitting an existing codebase with logical properties is tedious — finding every margin-left, understanding whether it is layout-directional or genuinely physical, rewriting each one. Building with logical properties from the start costs nothing. margin-inline-start is the same number of characters as margin-left: with a value; the intent is actually clearer.

The one caveat: use physical properties when the direction truly is physical and should not flip. A drop shadow that always trails to the bottom-right regardless of reading direction should use box-shadow with physical offsets. A scroll-indicator pinned to the physical right edge of the viewport should use right: 0. Logical properties model writing direction, not every use of a spatial axis.

Browser support

Logical properties are Baseline 2023: Chrome 89, Firefox 66, Safari 15. Every browser released in the last three years supports the full property set. No polyfill, no flag, no build-time transform.

🧠 Test yourself

Think it clicked? Take the 8-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The takeaway

margin-left means "the left edge." margin-inline-start means "the edge where text begins." In English they produce identical output. In Arabic they diverge — and the logical version is correct for both without any extra code. The [dir="rtl"] mirror block was never a solution; it was the cost of using physical properties in a world that doesn't read in one direction. Logical properties eliminate that cost. The next time you reach for margin-left, ask whether you mean the physical left or the inline start. Usually you mean the start.

Thanks for reading! Let's stay connected:

⭐ GitHub — follow me and star the projects: github.com/parsajiravand
📸 Instagram — frontend best practices, daily: @bestpractice___
💼 LinkedIn — linkedin.com/in/parsa-jiravand
✉️ Email (work & contract inquiries): bestpractice2026@gmail.com

Your CSS Grid cards look misaligned. `subgrid` is the fix you didn't know existed.

Parsa Jiravand — Thu, 16 Jul 2026 08:21:26 +0000

Here is a layout I have built more times than I can count.

You have a row of cards in a CSS Grid. Each card has a header, a body with variable-length content, and a footer with a button. The card with three lines of copy has its button sitting higher than the card with one line. You want all the footer buttons to sit on the same horizontal line.

So you try the usual fixes. You add flex: 1 to the body so it pushes the footer down. It pushes the footer to the bottom of its own card, but each card is a different height, so the buttons still don't align. You try a fixed height on the body. It works until someone adds a sentence of copy and the text overflows. You write four lines of JavaScript — querySelectorAll, getBoundingClientRect, find the max, set minHeight on each — and add a ResizeObserver to re-run it when the viewport changes.

That last approach works. It is also the wrong tool for a layout problem.

The real problem is structural: CSS Grid controls only direct children. Your card elements can participate in the outer grid's columns. But the content sections inside the cards — the header, body, footer — can't. Each card is its own formatting context, blind to the parent grid's row tracks.

subgrid changes that.

What `subgrid` actually does

When you apply grid-template-rows: subgrid to a grid item that spans multiple rows, the item stops defining its own row tracks. Instead, it inherits the parent grid's tracks for the span it occupies. Its children slot into the parent's rows directly.

.cards {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  grid-template-rows: auto 1fr auto;
  gap: 1.5rem;
}

.card {
  display: grid;
  grid-row: span 3;           /* occupy 3 row tracks in the parent */
  grid-template-rows: subgrid; /* inherit those 3 tracks */
}

With this in place, every .card-header sits in the first shared row track — sized to the tallest header across all cards. Every .card-body occupies the second track, a 1fr that expands consistently. Every .card-footer sits in the third track — sized to the tallest footer. No JavaScript. No fixed heights. The grid algorithm does the measurement.

The card alignment problem, solved

Here's the before and after:

Before — each card sizes independently:

.cards {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  gap: 1.5rem;
}

.card {
  display: flex;
  flex-direction: column;
}

.card-body {
  flex: 1; /* pushes footer to the bottom of *this* card only */
}

After — cards share the parent's row tracks:

.cards {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  grid-template-rows: auto 1fr auto;
  gap: 1.5rem;
}

.card {
  display: grid;
  grid-row: span 3;
  grid-template-rows: subgrid;
}

/* .card-header, .card-body, .card-footer need no special sizing rules */

The content sections slot into the shared tracks automatically. Every header aligns. Every footer aligns. The 1fr body row stretches uniformly across the entire row of cards.

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

Subgrid on both axes

You can opt into the parent's columns, rows, or both:

.card {
  display: grid;
  grid-column: span 2;
  grid-row: span 3;
  grid-template-columns: subgrid; /* inherit parent columns */
  grid-template-rows: subgrid;    /* inherit parent rows */
}

A card spanning two columns can now place its own children across both of those parent column tracks. This is useful in dense dashboard layouts — a wide stat card with an icon and a value that need to align with adjacent narrow cards' content.

Where subgrid actually belongs in your codebase

Subgrid solves a specific problem: nested content that should align with the outer grid's tracks. Common candidates:

Card grids — headers, body copy, and footers that must share horizontal baselines
Definition lists — term and value pairs in a two-column layout where nested fieldsets or groups must align with the outer columns
Form layouts — labels and inputs inside grouped sections that need to respect the outer grid's column widths
Navigation lists — icon, label, and badge in each row should share columns even when the rows are separate components

It does not replace flex-direction: column with flex: 1 in every card. That pattern is still appropriate when you only care that the footer reaches the bottom of its own card. Reach for subgrid the moment you hear yourself say "the buttons should all be on the same line."

Browser support

subgrid is Baseline 2023: Chrome 117, Firefox 71 (Firefox shipped it years earlier, in 2019, which proved demand existed), Safari 16. Every browser you are targeting for a new project supports it. No polyfill, no fallback grid, no build-time transform.

🧠 Test yourself

Think it clicked? Take the 7-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The takeaway

CSS Grid gave you a powerful coordinate system for your outer layout. subgrid extends that coordinate system into nested content that needs to participate in the same tracks. The alignment problem that has been driving you toward JavaScript — measuring heights, iterating over siblings, wiring up resize listeners — is a layout problem. The layout language has the answer now. Use it.

Thanks for reading! Let's stay connected:

⭐ GitHub — follow me and star the projects: github.com/parsajiravand
💬 Discord — join the frontend best-practices community: discord.gg/m7hqaTsmz
💼 LinkedIn — linkedin.com/in/parsa-jiravand
✉️ Email (work & contract inquiries): bestpractice2026@gmail.com

Your `.sort()` is mutating state. JavaScript finally gave you the fix.

Parsa Jiravand — Wed, 15 Jul 2026 08:22:27 +0000

Here is a bug I have shipped before. Maybe you have too:

const [tasks, setTasks] = useState(initialTasks);

function sortByPriority() {
  const sorted = tasks.sort((a, b) => b.priority - a.priority);
  setTasks(sorted);
}

This looks correct. It doesn't work correctly. Array.prototype.sort mutates the array in place and returns the same reference. sorted and tasks point to the same array. React sees the same reference it had before and skips the re-render. The UI doesn't update, or it updates inconsistently — it depends on whether anything else triggered a render cycle.

The fix you've been writing for years:

const sorted = [...tasks].sort((a, b) => b.priority - a.priority);

The defensive spread creates a new array, sort mutates that one, and you get a fresh reference React can track. It works. It's also cargo-cult boilerplate you have to remember to write, and it's easy to forget under pressure.

ES2023 added four methods that make the spread unnecessary.

`toSorted` and `toReversed`

Array.prototype.toSorted is the non-mutating version of sort. It returns a new sorted array and leaves the original unchanged:

const tasks = [
  { id: 1, priority: 2, title: 'Review PR' },
  { id: 2, priority: 5, title: 'Fix regression' },
  { id: 3, priority: 1, title: 'Update docs' },
];

const sorted = tasks.toSorted((a, b) => b.priority - a.priority);

console.log(sorted[0].title); // 'Fix regression'
console.log(tasks[0].title);  // 'Review PR' — untouched

The API is identical to sort. Any comparator that works with sort works with toSorted. The only difference is where the result lives.

toReversed is the same story for reverse:

const steps = ['write test', 'make it pass', 'refactor'];
const reversed = steps.toReversed();

console.log(reversed); // ['refactor', 'make it pass', 'write test']
console.log(steps[0]); // 'write test' — original intact

Array.prototype.reverse is one of the sneakier mutators because it returns this — the same array — making const rev = arr.reverse() look like it produced a copy when it didn't.

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

`toSpliced`

splice is the most powerful mutator in the array API. It inserts, removes, and replaces elements in place and returns the removed items — not the resulting array. toSpliced flips that contract: it returns the new array with the changes applied and leaves the original unchanged.

const items = ['a', 'b', 'c', 'd'];

// Remove 1 item at index 1, insert 'x' and 'y'
const updated = items.toSpliced(1, 1, 'x', 'y');

console.log(updated); // ['a', 'x', 'y', 'c', 'd']
console.log(items);   // ['a', 'b', 'c', 'd'] — untouched

The argument signature mirrors splice exactly: toSpliced(start, deleteCount, ...items). For insertions at a specific position, deletions from a slice, or multi-item replacements — it's the same mental model, no mutation.

`with` — replacing one item by index

This one is new in a different way. There was no mutable counterpart to replace because direct assignment (arr[i] = value) already did it. What didn't exist was a way to replace one item at a specific index without touching the original.

The workaround was either map:

const updated = items.map((item, i) => i === targetIndex ? newValue : item);

Or spread-and-reassign:

const updated = [...items.slice(0, i), newValue, ...items.slice(i + 1)];

Both communicate the intent poorly. with is the named operation:

const items = ['a', 'b', 'c', 'd'];
const updated = items.with(1, 'z');

console.log(updated); // ['a', 'z', 'c', 'd']
console.log(items);   // ['a', 'b', 'c', 'd']

It also supports negative indices — items.with(-1, 'z') replaces the last element — matching the same convention as Array.prototype.at.

Why this matters for React (and Zustand, and Immer, and anything with immutable state)

State in React must be treated as immutable. That rule is not a preference — React uses object identity to detect changes, so mutating an existing array and passing the same reference produces no re-render, regardless of whether the contents changed. The same applies to Vue's reactivity system, Zustand stores, Redux reducers, and any library that compares references before scheduling an update.

The immutable array methods give you the correct default:

// Before
setTasks(prev => [...prev].sort((a, b) => b.priority - a.priority));

// After
setTasks(prev => prev.toSorted((a, b) => b.priority - a.priority));

// Before — delete an item
setItems(prev => prev.filter((_, i) => i !== indexToRemove));

// After — splice idiom
setItems(prev => prev.toSpliced(indexToRemove, 1));

// Before — update one item
setItems(prev => prev.map((item, i) => i === idx ? { ...item, done: true } : item));

// After
setItems(prev => prev.with(idx, { ...prev[idx], done: true }));

Less ceremony, clearer intent, and no defensive spread to forget.

Browser support

All four methods are Baseline 2023: Chrome 110, Firefox 115, Safari 16, Node.js 20. That's roughly every browser released in the last two years. No polyfill needed if your browserslist target is reasonably current; a one-liner shim covers the rest.

🧠 Test yourself

Think it clicked? Take the 6-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The takeaway

Search your codebase for ].sort( and [... preceding a sort. Every [...arr].sort(fn) can become arr.toSorted(fn). Every [...arr].reverse() can become arr.toReversed(). Every arr.map((item, i) => i === idx ? … : item) that replaces by index can become arr.with(idx, …).

The defensive spread was never the right abstraction — it was a workaround for methods that should have had immutable variants from the start. They do now. Use them.

Thanks for reading! Let's stay connected:

⭐ GitHub — follow me and star the projects: github.com/parsajiravand
📸 Instagram — frontend best practices, daily: @bestpractice___
💼 LinkedIn — linkedin.com/in/parsa-jiravand
✉️ Email (work & contract inquiries): bestpractice2026@gmail.com

You've been writing this `reduce` a hundred times. `Object.groupBy` does it in one.

Parsa Jiravand — Tue, 14 Jul 2026 08:16:56 +0000

Open any frontend codebase and search for .reduce. I'll wait.

A meaningful fraction of those hits look like this:

const byStatus = tasks.reduce((acc, task) => {
  const key = task.status;
  if (!acc[key]) acc[key] = [];
  acc[key].push(task);
  return acc;
}, {});

Or, if the author has been around long enough, this tighter variant:

const byStatus = tasks.reduce((acc, task) => {
  (acc[task.status] ??= []).push(task);
  return acc;
}, {});

Both do the same thing: group an array by a key. It's one of the most common data transforms in any frontend codebase — group tasks by status, events by date, errors by code, users by role. You've written it dozens of times because JavaScript never had a built-in name for it.

It does now. And it has been in every major browser since early 2024.

`Object.groupBy` — the one-liner

const byStatus = Object.groupBy(tasks, task => task.status);

Pass an iterable and a callback. The callback returns the group key for each item. The result is a plain object where each key holds an array of the items that mapped to it.

const tasks = [
  { id: 1, status: 'done',        title: 'Ship it' },
  { id: 2, status: 'todo',        title: 'Write tests' },
  { id: 3, status: 'done',        title: 'Fix the bug' },
  { id: 4, status: 'in-progress', title: 'Review the PR' },
];

const grouped = Object.groupBy(tasks, t => t.status);
// {
//   done:         [{ id: 1, … }, { id: 3, … }],
//   todo:         [{ id: 2, … }],
//   'in-progress': [{ id: 4, … }],
// }

The callback can return any value that stringifies to a useful key — a status enum, a date string, a category slug, a computed bucket. Items that map to the same string land in the same array. Items that would map to undefined land under the key "undefined", which is a sign you should add a fallback in the callback.

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

When you need non-string keys: `Map.groupBy`

Object.groupBy coerces every key to a string. That covers most cases. If you need to group by something that isn't meaningfully stringifiable — an object reference, a boolean you want distinct from the string "true", or any value where identity matters — Map.groupBy is the variant:

const byPriority = Map.groupBy(tasks, task => task.priority > 5);

byPriority.get(true);  // high-priority tasks
byPriority.get(false); // everything else

The result is a real Map, so you access values with .get() and iterate with .entries(). Keys are the exact values your callback returned — no stringification, no coercion, no surprises.

A real-world example: the status board

Before groupBy, building a Kanban-style board from a flat API response involved one of two patterns. Either a filter per lane:

const lanes = ['todo', 'in-progress', 'review', 'done'];
const grouped = Object.fromEntries(
  lanes.map(status => [status, tasks.filter(t => t.status === status)])
);

That walks tasks once per lane — four passes for four columns. Or a reduce — one pass, but four lines of bookkeeping per developer who reads it.

With Object.groupBy:

const grouped = Object.groupBy(tasks, t => t.status);
const lanes = ['todo', 'in-progress', 'review', 'done'];
// `grouped` already has everything; `lanes` just controls render order

One pass. No ceremony. The intent is in the function name.

One subtle thing about the returned object

Object.groupBy returns an object with a null prototype — Object.create(null). It has no inherited toString, hasOwnProperty, or any of the usual Object.prototype methods. It's a pure data dictionary.

For most real uses this is exactly right: no prototype key collisions, no need for the hasOwnProperty dance before accessing a key. If downstream code needs a normal prototype — say, you're serializing it with a library that calls toString — wrap it: Object.assign({}, grouped). But in practice you rarely need to.

Support

Object.groupBy is Baseline 2024: Chrome 117, Firefox 119, Safari 17.4, Node.js 21. If your targets include browsers from the last two years you can use it today without a polyfill. For older targets a one-liner shim is trivial, but at this point you're more likely to just set a browserslist target that excludes the handful of users still on pre-2024 releases.

🧠 Test yourself

Think it clicked? Take the 6-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The takeaway

Object.groupBy isn't a convenience — it's the word for what you've been spelling out in four lines of reduce. Find the grouping reduces in your codebase, replace them, and delete whatever groupBy helper you wrote to avoid writing them inline. The operation has a name and a native implementation now; there's nothing left to carry.

DEV Community: Parsa Jiravand

You use a setTimeout to trigger CSS entry animations. `@starting-style` makes it unnecessary.

What @starting-style does

🎮 Try it yourself

Animating elements out of display: none

With native popover and <dialog>

Browser support and graceful degradation

🧠 Test yourself

The takeaway

You still write `finally { resource.close() }`. The `using` keyword does it automatically.

What using does

🎮 Try it yourself

Async teardown with await using

Making your own disposables

DisposableStack for dynamic resource groups

TypeScript and browser support

🧠 Test yourself

The takeaway

You've been doing Set math by hand. JavaScript finally shipped `.union()`, `.intersection()`, and friends.

The seven new methods

🎮 Try it yourself

A real-world example: permission diffing

The "set-like" argument

TypeScript support

Browser support

🧠 Test yourself

The takeaway

You keep escaping the Promise constructor. `Promise.withResolvers` does it right.

What Promise.withResolvers returns

🎮 Try it yourself

The event-to-Promise bridge

Async queues and message passing

Controlled flushing: waiting for a batch

When not to reach for it

TypeScript support

Browser support

🧠 Test yourself

The takeaway

You're rethrowing errors and losing context. `Error.cause` fixes that.

How Error.cause works

🎮 Try it yourself

Error chains instead of error strings

A real-world pattern: the service layer

TypeScript support

cause doesn't have to be an Error

Browser support

🧠 Test yourself

The takeaway

TypeScript Generics: The Complete Guide (with Cheat Sheet)

What you'll learn

Contents

Why generics exist

The mental model: a type parameter is a function argument for types

Stage 1: your first generic function

🎮 Try it yourself

Stage 2: generic interfaces and types

Stage 3: constraining a type parameter with extends

Stage 4: default type parameters

Stage 5: multiple type parameters and generic classes

Edge cases and gotchas

Best practices: when (not) to reach for generics

FAQ

What is a generic in TypeScript?

Is T extends SomeType the same as class inheritance?

Can I use a default value for a generic type parameter?

Is any the same as a generic?

Do generic types exist at runtime?

Cheat sheet

🧠 Test yourself

Key takeaways

Your scroll listener fires on every pixel. `IntersectionObserver` fires when visibility actually changes.

What it does

🎮 Try it yourself

Lazy loading an image

threshold and rootMargin

Analytics impression tracking

Cleanup in components

🧠 Test yourself

The takeaway

You're using Floating UI to position your tooltip. The browser does it natively now.

What `@starting-style` does

Animating elements out of `display: none`

With native `popover` and `<dialog>`

What `using` does

Async teardown with `await using`

`DisposableStack` for dynamic resource groups

What `Promise.withResolvers` returns

How `Error.cause` works

`cause` doesn't have to be an Error

Is `T extends SomeType` the same as class inheritance?

Is `any` the same as a generic?

`threshold` and `rootMargin`

`position-area` for common placements

Viewport overflow: `position-try-fallbacks`

What `subgrid` actually does

`toSorted` and `toReversed`

`toSpliced`

`with` — replacing one item by index

`Object.groupBy` — the one-liner

When you need non-string keys: `Map.groupBy`