DEV Community: Parsa Jiravand

Your fetch() Is Still Running After the User Left

Parsa Jiravand — Sun, 05 Jul 2026 09:12:47 +0000

When you fire a fetch() and the component that triggered it unmounts, the request keeps going. The server still processes it. When the response arrives, it calls back into whatever JavaScript it finds — a stale closure, a dead state setter, a global store that has already moved on. React's "Can't perform a state update on an unmounted component" warning is the polite version of this. The silent version is worse: results from an old query overwriting the current UI.

These aren't mysterious race conditions. They're the predictable result of starting async work and never telling it to stop.

The race condition hiding in every search box

The search input is the clearest example. The user types "reac", your debounce fires a request. Before it lands, they finish typing "react" and you fire another. Two requests, in flight at the same time, and no guarantee about which one finishes first.

If the "reac" request happens to be slower — network jitter, a cache miss, a heavier result set — it will land after "react" and overwrite the correct results with the wrong ones. The bug reproduces maybe one time in twenty on a local dev server, and consistently in production on a slow connection.

The fix isn't smarter debouncing. It's cancelling the previous request when a new one starts.

AbortController in plain terms

AbortController is a browser-native API for cancelling async work. You create a controller, pass its signal to fetch(), and call controller.abort() to cancel. If the response hasn't arrived yet, the fetch promise rejects with an AbortError.

const controller = new AbortController();

fetch('/api/search?q=react', { signal: controller.signal })
  .then(res => res.json())
  .then(data => setResults(data))
  .catch(err => {
    if (err.name === 'AbortError') return; // expected — not a real error
    setError(err);
  });

// Somewhere else, when we no longer need this request:
controller.abort();

Two things to internalize: signal is how the controller knows which request to cancel, and AbortError is intentional — catching and ignoring it is correct behavior, not a smell.

The React pattern: cancel in the cleanup function

useEffect's cleanup runs when the component unmounts and before the effect re-runs due to a dependency change. That makes it the natural place to cancel.

useEffect(() => {
  const controller = new AbortController();

  fetch(`/api/search?q=${query}`, { signal: controller.signal })
    .then(res => res.json())
    .then(data => setResults(data))
    .catch(err => {
      if (err.name !== 'AbortError') setError(err);
    });

  return () => controller.abort();
}, [query]);

When query changes, React runs the cleanup (aborting the in-flight request) before starting the next effect (firing a new one). The stale "reac" request is cancelled the moment "react" is typed — it will never call back into state.

When the component unmounts — navigation, modal close, conditional render — the cleanup fires and the pending request dies. No stale updates, no console warnings.

It's not just for fetch()

The signal property on an AbortController isn't coupled to fetch. Any API that accepts an AbortSignal can participate, and you can check signal.aborted in your own async loops:

async function processItems(items, signal) {
  for (const item of items) {
    if (signal.aborted) return; // bail out before the next iteration
    await processOne(item);
  }
}

const controller = new AbortController();
processItems(largeList, controller.signal);

// A cancel button, a timeout, a navigation — any of these can call:
controller.abort();

Check signal.aborted at each yield point. This pattern replaces global boolean flags and ad-hoc "is this still relevant?" tracking with a single, standard primitive that any caller can trigger.

For timeouts specifically, AbortSignal.timeout(ms) is cleaner than the manual approach:

// Auto-aborts after 5 seconds — no controller to hold, no setTimeout to clear
fetch('/api/slow-endpoint', { signal: AbortSignal.timeout(5000) })
  .catch(err => {
    if (err.name === 'TimeoutError') handleTimeout();
  });

Note that timed-out requests throw TimeoutError, not AbortError — they're distinct cases, and it's useful to handle them differently.

What about React Query, SWR, or TanStack?

Data-fetching libraries handle this for you. React Query wires up an AbortController under the hood and cancels outgoing requests when a query key changes or a component unmounts. Understanding the pattern still matters: it's why the library behaves correctly, and you'll need the manual version any time you write custom fetch logic outside the library's boundaries.

The takeaway

Async code doesn't stop running because you stopped caring about it. A fetch() in flight is a real resource — a server-side computation, a response that will arrive and call something — and if nothing cancels it, it will complete against whatever state it finds.

AbortController is the correct primitive for this. The cost is three lines: create a controller, pass signal to fetch, return controller.abort from the cleanup. The return is eliminating an entire class of subtle, non-deterministic bugs.

If you've ever filed a race condition as "can't reliably reproduce," there's a good chance the unfiled fix is a missing controller.abort().

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 reached for !important again. @layer is the real fix.

Parsa Jiravand — Sat, 04 Jul 2026 08:44:01 +0000

You typed !important. Be honest — you did. The third-party reset was winning, your override wasn't sticking, the clock was ticking, and !important made the red squiggle go away.

I've done it too. I've added an ID selector I didn't want, inlined a style I'd be ashamed of, and stacked !important on !important like sandbags against a flood.

Here's what took me too long to see: none of that was a selector problem. It was an architecture problem wearing a selector costume. And @layer is the fix that's been in every browser since 2022 while we kept reaching for the sandbags. Let me show you why the fight was unwinnable — and then how a single line at the top of your stylesheet ends it.

Why you keep losing the specificity war

Picture your stylesheet's contents thrown into one room: the third-party reset, your base typography, component styles, utility classes, that library you imported. They're all in the same cascade, all negotiating through one currency — selector weight. Whoever writes the heavier selector wins.

That's the whole problem. There's no ordering of concerns, just a brawl refereed by specificity. So when an imported section > main .btn outweighs your .btn, your only moves are to out-specify it or detonate !important. You're not fixing anything. You're escalating an arms race you started by having concerns share a room with no rules.

One line that changes the currency

@layer lets you name layers and fix their priority order up front. A rule in a higher layer beats a rule in a lower layer regardless of specificity.

/* later layers win — declare the order once, at the top */
@layer reset, base, components, utilities;

Read what that buys you. A bare .btn in utilities now beats section > main > article .btn in base — not because you found a heavier selector, but because the layer order says utilities outrank base, and the cascade checks layer order before it ever counts specificity.

Specificity still breaks ties within a layer. Between layers, your declared order is law. The currency changed.

The third-party reset problem, gone

This is where it pays for itself on day one. Every project that pulls in a reset, Tailwind's preflight, or a component library has fought this exact fight: some imported rule outweighs yours, and you write overrides to undo work you didn't author.

/* shove third-party styles into low layers */
@import url("reset.css") layer(reset);
@import url("ui-library.css") layer(thirdparty);

/* yours, higher — wins automatically */
@layer app {
  a      { color: var(--color-link); }
  button { border-radius: var(--radius-sm); }
}

No !important. No escalation. Third party goes low, your code goes high, low always loses. And the rule is written once, at the top, where the next person can read the whole hierarchy in five seconds instead of reverse-engineering it from forty scattered overrides.

The four-layer pattern that fits most apps

@layer reset, base, components, utilities; /* lowest → highest */

@layer reset {
  *, *::before, *::after { box-sizing: border-box; }
}
@layer base {
  body { font-family: var(--font-sans); line-height: 1.6; }
  a    { color: var(--color-link); }
}
@layer components {
  .card { border-radius: var(--radius-md); padding: 1.5rem; }
  .btn  { display: inline-flex; padding: 0.5rem 1rem; }
}
@layer utilities {
  .hidden  { display: none; }
  .sr-only { position: absolute; width: 1px; height: 1px; overflow: hidden; }
}

When .card and .hidden collide on one element, utilities wins — not because of a cleverer selector, but because the architecture says so. The layer boundary is the referee you never had.

Quick — before you scroll, predict this one: you write a plain a { color: red } outside every layer. Does it beat the a rule inside your base layer, or lose to it?

The answer trips everyone (and it's the migration path)

It wins. Styles written outside any named layer sit in an implicit unlayered group that outranks every named layer. Feels backwards the first time. It's deliberate — and it's exactly what makes adoption safe.

@import url("reset.css") layer(reset);

/* unlayered — still beats the reset, exactly like before */
a { color: var(--color-link); }

Your existing, un-migrated CSS keeps behaving precisely as it does today. So you adopt incrementally: wrap the third-party imports first, confirm the reset stops fighting you, then move your own styles into layers whenever you're ready. Nothing breaks on the day you start, because unlayered code keeps winning until you choose otherwise.

The new question in DevTools

One honest cost: debugging gains a dimension. "Why is this rule losing?" used to mean "find the higher-specificity rule." Now it can also mean "which layer is it in?" Chrome DevTools already groups the Styles panel by layer, so it's visible — but it's a new place to look.

The upside outweighs it. Once layers are declared, you stop tracing specificity chains and start asking "is this rule in the right layer?" — a question with a clear, checkable answer instead of a math problem.

So put the `!important` down

That sandbag you reached for? It treats a structural problem as a selector problem, which is why it never actually holds. Specificity battles are the symptom. The disease is a stylesheet where every rule negotiates with every other rule through selector weight alone — and @layer adds the dimension the cascade was always missing: explicit, author-controlled ordering of concerns.

It's in Chrome 99, Firefox 97, and Safari 15.4 — shipping since early 2022. No polyfill, no build step. The migration is incremental and the safety net (unlayered wins) is built in.

The takeaway for tomorrow: the next time your finger hovers over !important, ask whether a layer boundary is the real fix. It usually is.

What's the worst specificity hack still load-bearing in your codebase right now — the #app #main .thing.thing chain, the !important nobody dares touch? Confess it in the comments and let's figure out which layer it belongs in.

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

The page transition you pay a library for is now free

Parsa Jiravand — Fri, 03 Jul 2026 09:26:36 +0000

Picture the last time you wired up a page transition. The leaving page's exit. The entering page's entrance. The awkward in-between where both exist at once. Maybe a getBoundingClientRect() here, a hand-tuned transform there, a library install to coordinate it all.

That whole apparatus was for an effect a native app gets by existing.

Here's the part that'll annoy you: the browser does it now. The simplest version — a smooth cross-fade across your entire site — costs exactly one CSS rule. The fancy version, where a thumbnail morphs into a full hero image as you navigate, costs two. And neither one needs a single line of JavaScript. Let me show you the one-rule version first, then build up to the morph.

One rule. The whole site cross-fades.

If you've got a regular multi-page app — separate HTML documents per page — opt into automatic transitions with this:

@view-transition {
  navigation: auto;
}

Drop it in your stylesheet. Navigate. Every page change is now a gentle cross-fade. No JS, no library, no event listeners, no coordination.

What's the browser actually doing? It screenshots the outgoing page, runs the navigation, then animates from that screenshot to the new page — a 300ms opacity cross-fade by default. Exactly the baseline you'd have built by hand. And it's strictly opt-in: without that rule, navigation stays instant, same as always.

That's the freebie. But "everything cross-fades" isn't why this API matters. Hold that thought.

The mental model that makes the rest click

Every view transition is the same three beats:

Capture — the browser snapshots the current page.
Change — your navigation (or DOM update) runs.
Animate — the browser builds two pseudo-elements, ::view-transition-old and ::view-transition-new, and tweens between them.

This is the opposite of how a motion library thinks. A library makes you describe the motion: this exits left, that enters right, here's the easing. View Transitions make you describe what should transition — the browser figures out how by diffing before against after.

Want something other than a cross-fade? Style those pseudo-elements like anything else:

::view-transition-old(root) {
  animation: 250ms ease-in both fade-out, 250ms ease-in both slide-out;
}
::view-transition-new(root) {
  animation: 250ms ease-out both fade-in, 250ms ease-out both slide-in;
}
@keyframes slide-out { to   { transform: translateX(-30px); } }
@keyframes slide-in  { from { transform: translateX(30px);  } }

Now every navigation is a subtle directional slide. Still zero JavaScript.

The trick worth the price of admission

Here's the thought you parked earlier. The real payoff isn't the cross-fade — it's telling the browser "this element on page A is the same element as that one on page B." Give them a shared name and the browser morphs one into the other.

/* list page */
.product-card[data-id="42"] img { view-transition-name: product-hero-42; }

/* detail page */
.product-hero-image { view-transition-name: product-hero-42; }

Navigate from the list to the detail page and the thumbnail flies into place as the full hero — position, size, shape, all interpolated. You wrote no animation. You declared an identity, and the browser handled every pixel of geometry.

Be honest: how much code did this take last time? getBoundingClientRect() on both elements, the delta math, a transform to fake the start position, timing to undo it. A few hundred lines, easy. Here it's two rules whose names match.

One gotcha: view-transition-name must be unique in the DOM at any instant. Rendering a list of cards? Set the name dynamically so only the card being navigated carries it, or scope it with :has() to the active state.

SPAs get the same engine, behind a function

If you own navigation programmatically, the JS API exposes that same capture-change-animate cycle:

// before:
updatePageContent();

// after:
document.startViewTransition(() => updatePageContent());

Pass a callback that mutates the DOM. The browser captures before, runs your function, captures after, plays the transition. Your update logic doesn't change — you wrap it. React Router and the Next.js App Router are threading this into their navigation primitives, but underneath, the primitive never changes: snapshot, update, animate.

Adding it can't break anything

This is the part that should make you comfortable shipping it today: it's purely additive. Browsers without support — and the holdouts are thinning, with Chrome, Firefox, and Safari all shipping it — just navigate instantly, like they always did. The guard is a one-liner:

if (document.startViewTransition) {
  document.startViewTransition(() => updatePageContent());
} else {
  updatePageContent();
}

No polyfill, no fallback CSS, no broken state. The browser plays the transition or it doesn't.

Where it fits — and where it doesn't

Reach for View Transitions on navigational context changes: moving between pages, opening a detail from a list, expanding an inline panel. "You're going from here to there" maps onto the API naturally.

Don't reach for it on micro-interactions inside a view: hovers, spinners, a toggle's state change, a choreographed timeline. Those want CSS transition/animation or a real motion library where you control every keyframe.

The line: animation driven by navigation between views → View Transitions. Animation driven by interaction within a view → regular CSS or a library.

Back to that library you were about to install

The honest scope: View Transitions won't replace intricate choreography — that still needs more. What they replace is the default case. The clean cross-fade. The hero morph. The transition every multi-page app should have and usually skips, because nobody wanted to pull in Framer Motion for something that basic.

Takeaway for tomorrow: before you add an animation library for navigation, ask what one CSS rule already buys you. Often it's most of what you needed — and the rest is two matching names.

What's the page transition you abandoned because wiring it up wasn't worth it? Try the one-rule version on it tonight and tell me how close it got in the comments.

:has() isn't a parent selector. It deletes JavaScript.

Parsa Jiravand — Thu, 02 Jul 2026 07:18:03 +0000

Open your codebase and search for classList.toggle. Go ahead, I'll wait.

I'd bet a real chunk of those hits are the same little chore: the user checks a box, focuses a field, or makes a selection, and you respond by toggling a class on some parent element so its styling can react. A listener, a class, matching CSS for that class. You've written that dance dozens of times.

Most of it can be deleted. Not refactored — deleted. The reason it survives is that everyone learned :has() as "the parent selector," and that label quietly hides what it actually is. Stick with me and you'll never write that class-toggle the same way again.

Why "parent selector" is the wrong name

Yes, :has() can style a parent based on a child. But pin it to that one trick and you'll miss the whole feature. :has() tests a condition — any selector you'd normally write, evaluated against an element's contents instead of the element itself. The thing making it true can be a descendant, a sibling, a count, or the absence of something.

/* a parent based on a child — the famous case */
.card:has(img) { ... }

/* focus state buried deep in the subtree */
.form-group:has(:focus-visible) { ... }

/* checked state */
.option-row:has(input:checked) { background: var(--selected-bg); }

/* absence — the logical complement */
.card:not(:has(img)) { ... }

/* count — restyle a grid by how many children it holds */
.grid:has(> :nth-child(4)) { grid-template-columns: repeat(4, 1fr); }

Stare at that last one. You're changing a grid's layout based on how many items it contains — in pure CSS, no JavaScript, no server-rendered class. That's not "selecting a parent." That's a conditional reading live DOM state. Different mental model entirely.

The class of JavaScript that just disappears

Here's the pattern :has() retires. You've written this:

// The old bridge: JS exists only to move a class up the tree
checkbox.addEventListener("change", () => {
  row.classList.toggle("is-checked", checkbox.checked);
});

Why does this code exist at all? Because CSS selectors only ever flowed down — a parent could style its children, but a child could never trigger a style on its ancestor. So we hired JavaScript as a messenger. :has() makes the messenger redundant:

/* The whole listener, gone */
.option-row:has(input[type="checkbox"]:checked) {
  background: var(--selected-bg);
  font-weight: 600;
}

The listener is gone. The class is gone. And — this is the part that's easy to undervalue — the style is now true whenever the DOM is in that state. On first render. After a back-navigation. When state is restored from a URL. There's no window where the DOM has updated but the class hasn't caught up yet, because there's no class to catch up.

Three you can paste in today

Field-group validation. Light up the whole group — label, input, hint — when it holds an input the user touched and left invalid:

.field-group:has(input:invalid:not(:placeholder-shown)) {
  border-color: var(--color-error);
}
.field-group:has(input:invalid:not(:placeholder-shown)) label {
  color: var(--color-error);
}

That used to be a blur listener, a wrapper class, and matching CSS. Now: two rules.

Empty state. Show a placeholder when a list has no items:

.todo-list:not(:has(li)) + .empty-state { display: block; }

No JS tracking item counts. The empty state appears the moment the last li leaves.

Checkbox-driven panel. A toggle reveals its settings panel:

.settings-section:has(input[type="checkbox"]:checked) .settings-panel {
  display: grid;
}

The browser's own form state is the source of truth, and CSS reads it directly. No syncing.

The one place to slow down

:has() isn't free. Matching a class is the browser reading an attribute; matching :has() means evaluating the inner selector against descendants. For static content and low-frequency state — validation, toggles, checked state — the cost is imperceptible. Ship it.

Where to be deliberate: high-frequency, continuously-changing inputs. :has() keyed off scroll position, or nested inside :hover on a list of thousands of rows. The rule of thumb: anywhere you'd have reached for a debounce on the JS side, give the :has() version a second look and profile it.

So which JS is still pretending to be CSS?

Back to that classList.toggle search you ran. The framing that unlocks the cleanup isn't "where can I select a parent" — it's this: whenever you catch yourself toggling a class purely to drive styling off some child's state, stop and ask whether :has() expresses that condition directly. More often than you'd guess, it does. When it does, the CSS shrinks, the JS evaporates, and the styling is correct from the very first paint because it's reading state instead of reacting to it.

:has() is in Chrome, Firefox, Safari, and Edge — no flag, no polyfill, no waiting. It's not a parent selector. It's a stylesheet that can finally read its own document.

So go run the search. How many of your classList.toggle calls are really a :has() rule in a trench coat? Drop the gnarliest one in the comments and let's rewrite it.

Your Save button waits 300ms for nothing. Stop it.

Parsa Jiravand — Wed, 01 Jul 2026 07:42:41 +0000

Tap the heart on Instagram. It fills in red before your finger leaves the glass. Swipe to archive in Gmail — gone, instantly. Neither app waited for a server to say "okay." They assumed success and moved on.

Now open the app you're building and click "Save." Watch the button freeze. One-Mississippi. The spinner. Then the UI updates.

That lag isn't the network being slow. It's a decision your code made: wait for the server before showing the user anything. You can make the other decision. The instant version is maybe four lines of code — but if you stop there, you've built a beautiful lie that desyncs the first time the network hiccups.

The fast part is easy. The part everyone gets wrong is what happens when the server says no.

What the slow version actually costs

Here's the pattern in nearly every codebase. Wait, then reflect:

// Pessimistic: nothing happens on screen until the server answers
async function handleLike(postId: string) {
  setLoading(true);
  await api.likePost(postId);   // 300ms of dead air
  setLiked(true);
  setLoading(false);
}

The user taps. Nothing. Then the heart turns red. Technically correct, feels sluggish — and ~300ms is roughly the point where an interaction stops feeling like a direct response and starts feeling like a request you submitted. Worse, this fires on every single tap.

Act first, apologize later

Flip the order. Update the UI as if it already worked, then quietly reconcile:

// Optimistic: change now, roll back only if the server disagrees
async function handleLike(postId: string) {
  setLiked(true);            // instant
  setCount(c => c + 1);      // instant

  try {
    await api.likePost(postId);
  } catch {
    setLiked(false);         // rollback
    setCount(c => c - 1);    // rollback
    toast.error("Couldn't save — try again.");
  }
}

The heart fills the instant you tap. On the 99% happy path, the await resolves and nothing visible happens — the optimistic state was right. On the rare failure, the heart goes grey and a toast explains why.

Spot what's carrying the whole pattern? It's not the two set calls at the top. Anyone writes those. It's the catch block — the part that knows exactly how to undo what it just did. That's the half people skip, and it's the half that matters.

Where manual rollback falls apart

A toggle is easy: one boolean to flip back. But the moment you're optimistically editing a list — adding, removing, reordering — manual rollback turns into a bookkeeping nightmare. What was the array before? What if a background refetch lands mid-mutation?

This is exactly the mess TanStack Query's mutation lifecycle is shaped to clean up:

const mutation = useMutation({
  mutationFn: (newTodo: Todo) => api.createTodo(newTodo),

  onMutate: async (newTodo) => {
    // Stop in-flight refetches from clobbering our optimistic write
    await queryClient.cancelQueries({ queryKey: ["todos"] });

    const previous = queryClient.getQueryData(["todos"]);          // snapshot
    queryClient.setQueryData(["todos"], (old: Todo[]) =>
      [...old, newTodo]);                                          // apply
    return { previous };                                           // stash for rollback
  },

  onError: (_err, _newTodo, context) => {
    queryClient.setQueryData(["todos"], context?.previous);        // restore
    toast.error("Failed to add todo.");
  },

  onSettled: () => queryClient.invalidateQueries({ queryKey: ["todos"] }), // re-sync
});

Read it as four jobs, one each: snapshot → apply → restore-if-error → sync-always. onMutate saves and applies. onError puts the snapshot back. onSettled re-fetches no matter what, so the screen and the server agree at the end.

That cancelQueries line is the one everyone forgets, and it bites. Without it, a refetch that was already in flight can finish after your optimistic write and overwrite it with stale data — a flicker that's maddening to debug because it only shows up under the right timing.

The actions you should never fake

Optimistic UI is not free confidence. It fits low-stakes, high-frequency actions where failure is rare and undo is clean: likes, favorites, checking off a task, toggling a setting.

It's the wrong tool when:

The action is irreversible. Placing an order, sending a message, deleting an account. Make the user wait and confirm — don't paper over real consequences with a fake "done."
The server computes the result. A generated ID, a recalculated total, a merged state — you can't honestly predict it, so don't pretend to.
Retries aren't safe. If a duplicate call could double-charge, slow down on purpose.

My one-line test: would the user be upset to learn it silently failed? Spinner. Would they just shrug and tap again? Go optimistic.

So why does the Save button still wait?

Because the happy path was the easy 90% and the team never built the other 10%. That's the whole story. Every implementation nails "update the UI fast." The rollback — snapshot, restore, tell the user — is what separates a polished app from one that quietly lies to people.

The takeaway for tomorrow's standup: optimistic updates aren't a library, they're a discipline — always handle the failure path explicitly. Snapshot before you touch state. Restore on error. Say something went wrong. Most users will never see those three steps. The ones who do will trust you more, not less.

What's the worst optimistic-update desync you've shipped — the ghost item, the double-count, the flicker that wouldn't reproduce? I'll go first in the comments.

Your card breaks in the sidebar. Here's the real fix.

Parsa Jiravand — Tue, 30 Jun 2026 07:30:00 +0000

You built a card. Image, title, a line of copy. In the main content column it's gorgeous — image left, text right, everything breathing.

Then someone drops it into the sidebar.

Now the image is squashed next to three words per line, the title wraps four times, and the whole thing looks broken. You open DevTools, check your breakpoints, and they're all firing correctly. The viewport is wide. So why does your card look like it's having a stroke?

Here's the punchline up front: the bug isn't in your CSS. It's in the question your CSS is allowed to ask. And the fix is one line.

The question media queries can't answer

For fifteen years, the only responsive question we could ask was "how wide is the window?" That's what a media query is. Resize the viewport, cross a breakpoint, restyle.

Which works fine — right up until you build a component meant to live in more than one place.

Your card doesn't care how wide the window is. It cares how wide it is. And those two numbers have nothing to do with each other. A 1400px desktop can hand your card a 220px sidebar. The media query sees "1400px — go wide!" and lays out side-by-side in a slot that's narrower than the image.

/* The card asks the window. The window has no idea where the card is. */
@media (min-width: 600px) {
  .card { grid-template-columns: 200px 1fr; }
}

Quick gut check before you scroll: how have you solved this before? Be honest.

If you're like most of us, the answer is one of three hacks: a compact prop threaded down through five components, a ResizeObserver wired up in JavaScript, or two near-identical card variants you swap by hand. I've shipped all three. They're all workarounds for the same missing primitive — a way for a component to ask its own container, not the window, how much room it's got.

One declaration changes the question

That primitive shipped. It's called a container query, and it's in every major browser — Chrome, Firefox, Safari, Edge — no flag, no polyfill.

You do two things. Mark a parent as a container. Query that instead of the viewport.

/* 1. Tell the parent it's a query container */
.card-wrapper {
  container-type: inline-size;
}

/* 2. The compact default — image on top */
.card {
  display: grid;
  grid-template-rows: auto 1fr;
}

/* 3. Go side-by-side only when MY container has the room */
@container (min-width: 500px) {
  .card {
    grid-template-columns: 200px 1fr;
    grid-template-rows: unset;
  }
}

Read that @container line out loud: "when my container is at least 500px, go wide." Not the window. The container.

Now drop the exact same card into the 220px sidebar and it stays stacked, because its container is 220px. Drop it into the wide grid and it opens up. One component, two layouts, zero JavaScript, zero props. The card finally knows where it lives.

When the layout nests, name the container

Sometimes the thing you want to respond to isn't the immediate parent — it's a layout region three levels up. Name your containers and query the one you mean:

.sidebar { container-type: inline-size; container-name: sidebar; }
.main    { container-type: inline-size; container-name: main; }

/* This title responds to the sidebar specifically */
@container sidebar (min-width: 300px) {
  .card-title { font-size: 1.25rem; }
}

The old way to make a deeply nested element aware of a high-level region was a ResizeObserver, a React context, and a prop-drilling session. Here it's two declarations. That's the whole feature.

So is `@media` dead? No — and here's the line

This is the part people get wrong: container queries don't replace media queries. They have different jobs, and mixing them up is its own mess.

Media query → page-level structure. One column vs. two. Collapsing the nav. A full-bleed hero. Anything that genuinely answers to the viewport — including print and prefers-reduced-motion.
Container query → anything reusable that gets dropped into varying space. Cards, tables, form fields, media objects.

The heuristic that's never failed me: the layout skeleton is a media query; everything you hang on it is a container query.

The bonus you'll notice in Storybook

Here's a side effect I didn't expect. Build a card with media queries inside it and your Storybook preview lies — it shows the component at the story frame's viewport width, not the width it'll get in production. The preview looks fine; the real layout breaks.

Swap to container queries and the preview tells the truth. Resize the story panel and the card adapts, because "context" now lives in the CSS instead of being inferred from the window. What you see in isolation is what you ship.

The fix was one line — and a better question

Remember the broken sidebar card? container-type: inline-size on its wrapper. That's it. The layout you already wrote starts working the moment the card can see its own container instead of guessing from the window.

The takeaway you can repeat to a teammate tomorrow: stop asking "how wide is the window?" and start asking "how wide am I?" Once the question changes, the component designs itself.

So — how many compact props are still threaded through your codebase right now? Go count. I bet most of them want to be a single @container rule. Tell me what you find in the comments.

The URL Is Your Best State Manager

Parsa Jiravand — Mon, 29 Jun 2026 07:59:09 +0000

There's a category of bug I see in almost every SPA I touch: the user applies a filter, sorts a table, pages through results — and then refreshes, or pastes the link to a colleague, and all of it is gone. The bug report says "it doesn't remember my state." The root cause is almost always the same: that state lived in useState, when it should have lived in the URL.

This is a mental model, not a framework feature. It applies equally in React, Vue, Svelte, or plain JS. The URL is a state management primitive you already have — built into every browser, shared for free — and most frontend teams underuse it.

What belongs in the URL

Not all state belongs there. The key question is: would a user want to share or bookmark this?

State	URL?	Why
Active tab / current view	Yes	Direct-linkable, shareable
Search query	Yes	Back button works, shareable
Filters, sort order	Yes	Reproducible results
Pagination cursor	Yes	"Send me the page you're on"
Form draft in progress	No	Ephemeral, user-session only
Hover state, tooltip open	No	Ephemeral UI state
Auth tokens	Never	Security hazard

The filter and the modal-open state are both "UI state," but they're different in kind. One the user would share; one they wouldn't. Put the first in the URL and leave the second in component state.

What you gain for free

When search/filter/sort state lives in the URL, you get three things without writing a single extra line of code:

Refresh survival. The user filters a table, refreshes — the filter is still there.
Shareable links. "Here's what I'm looking at" works via copy-paste.
Browser history. Back and forward navigate state transitions, which is what users expect.

These are not small wins. "Back button broke my filters" is a real UX bug, and moving to URL state fixes it completely and permanently.

The pattern in React

Here's the before/after for a search input:

// Before: state dies on refresh
function SearchPage() {
  const [query, setQuery] = useState("");
  return (
    <input
      value={query}
      onChange={e => setQuery(e.target.value)}
    />
  );
}

// After: state lives in the URL
import { useSearchParams } from "react-router-dom"; // or Next.js's useSearchParams

function SearchPage() {
  const [params, setParams] = useSearchParams();
  const query = params.get("q") ?? "";

  return (
    <input
      value={query}
      onChange={e =>
        setParams(p => { p.set("q", e.target.value); return p; })
      }
    />
  );
}

The component is roughly the same size. The URL is now ?q=typescript. Refresh — still there. Copy the URL — the recipient sees the same results. The back button undoes the last keystroke (or use replace instead of push to keep history clean for every keystroke).

For more complex state — multiple filters, sort columns, numeric values — a library like nuqs handles serialization, type coercion, and history mode in a useState-compatible API:

import { useQueryState, parseAsInteger } from "nuqs";

const [sort, setSort] = useQueryState("sort", { defaultValue: "date" });
const [page, setPage] = useQueryState("page", parseAsInteger.withDefault(1));

Typed URL params, familiar API, zero custom serialization logic.

The failure mode to watch for

Don't put too much in the URL. It's for state the user would meaningfully share — not for every piece of transient UI. A deeply nested JSON blob in a query string is the wrong answer. Keep it flat, keep it readable.

?status=active&sort=name&page=2 is good. ?state=eyJzdGF0dXMiOiJhY3RpdmUi... is a red flag.

If your state is too complex to flatten into a few readable params, it may genuinely belong in a database or session store, not the URL. The URL should be a narrow representation of "what the user is looking at" — not a full snapshot of the app.

The takeaway

The URL is a first-class state management layer that every browser already implements, every user already understands, and most SPAs leave mostly unused. Before you reach for useState, ask: would the user want to share or bookmark this? If yes, put it in the URL — you get refresh survival, deep links, and a working back button for free.

That's not a third-party library or a framework feature. It's how the web was designed. Use it.

Server Components Without the Hype: A Mental Model That Sticks

Parsa Jiravand — Sun, 28 Jun 2026 09:41:34 +0000

React Server Components confused a lot of people, and most of the confusion comes from pattern-matching them onto things we already knew — "oh, it's just SSR," or "it's like getServerSideProps." It isn't, quite. Here's a mental model that actually sticks.

The one distinction that matters

Forget rendering for a second. The real split is where a component's code lives and runs:

A Server Component runs only on the server. Its code never ships to the browser. It can read your database, touch the filesystem, use secrets — and then it disappears, leaving behind only the UI it produced.
A Client Component is the React you already know: its code ships to the browser, and it can use state, effects, and event handlers.

That's the whole core idea. Server Components are components whose JavaScript the user never downloads. Everything else follows from that.

Why this is different from SSR

Classic SSR renders your entire app to HTML on the server, then ships all the JS to the browser to "hydrate" it — make it interactive. You paid for the HTML and the full bundle.

RSC lets you say: this part of the tree is just display — render it on the server and don't send its code at all. Only the genuinely interactive bits become Client Components and ship their JS. The static 80% of a typical page stops costing you bundle size.

// Server Component — runs on the server, ships zero JS to the client.
// It can await data directly. No useEffect, no loading spinner plumbing.
async function ArticlePage({ id }: { id: string }) {
  const article = await db.articles.find(id); // safe: never runs in the browser
  return (
    <article>
      <h1>{article.title}</h1>
      <Markdown>{article.body}</Markdown>
      <LikeButton articleId={id} /> {/* the ONE interactive island */}
    </article>
  );
}

"use client"; // this directive marks the boundary — code below ships to the browser
function LikeButton({ articleId }: { articleId: string }) {
  const [liked, setLiked] = useState(false);
  return <button onClick={() => setLiked(!liked)}>{liked ? "♥" : "♡"}</button>;
}

The page's data-fetching and markup rendering cost zero client JS. Only LikeButton — the part that needs to do something on click — gets shipped.

The rules that trip people up (and why they exist)

Server Components can't use useState/useEffect/event handlers. They don't exist on the client, so there's no "interactive" lifecycle to hook into. If you need interactivity, you've found a Client Component.
You can pass a Server Component into a Client Component as children, but you can't import one into a client module. Because the moment you import it into client code, its server-only code would have to ship — defeating the point.
"use client" marks a boundary, not a file-by-file choice. Everything imported below that boundary is in client-land too. Put the directive as deep in the tree as you can.

Once you internalize "Server Components are the code that never ships," every one of those rules stops feeling arbitrary and starts feeling obvious.

When to actually reach for it

Default to Server Components. Make a component a Client Component only when it needs state, effects, browser APIs, or event handlers.
Push the "use client" boundary down. A whole page marked client-side throws away the benefit; an interactive leaf node keeps it.
Don't fight it for purely static sites. If there's barely any interactivity, a simpler static-generation setup may be all you need — RSC earns its complexity on data-heavy, partially-interactive apps.

The takeaway

Server Components aren't "SSR with extra steps." They're a way to write parts of your UI whose code never leaves the server — so the browser downloads only the JavaScript that genuinely needs to run there. Hold onto that one sentence and the rest of the model assembles itself.

TypeScript Won. Here's What That Actually Bought Us.

Parsa Jiravand — Sun, 28 Jun 2026 07:31:53 +0000

Nobody seriously argues about adopting TypeScript anymore. New frontend projects default to it; the holdouts are legacy codebases and the occasional throwaway script. The debate is over, TypeScript won.

But "won" is the boring part. The interesting part is what types turned out to be good for — which is more, and different, than the original pitch of "catch typos before runtime."

Types are the cheapest documentation you'll never have to update

A function signature is documentation that can't go stale, because the compiler fails the build the moment it lies.

function scheduleReminder(
  userId: string,
  at: Date,
  channel: "email" | "push" | "sms",
): Promise<ReminderId>;

You already know almost everything about calling this without reading a single comment: what it needs, what it returns, that channel is one of exactly three strings. A comment claiming the same things could rot the next time someone adds a "slack" channel and forgets to update it. The type can't — adding "slack" to the union forces every call site to be reconsidered.

Types make refactoring a mechanical activity instead of an act of courage

In a large untyped codebase, renaming a widely-used field is genuinely scary — you're grepping strings and praying. In a typed one, you change the type and the compiler hands you the complete to-do list of everything that broke. Refactoring stops being "risky" and becomes "tedious but safe," which is exactly the trade you want. Whole categories of "we can't touch that, it's too entangled" simply dissolve.

The payoff nobody planned: types are the contract AI codegen needs

Here's the part that wasn't in the original sales pitch. The more machine-readable your boundaries are, the more reliably an AI assistant can operate inside them.

Ask a model to "add a field to this object" in untyped JavaScript and it's guessing at shape from usage. Ask it in TypeScript and the type is the spec — it knows precisely what's allowed, and its mistakes surface as compile errors instead of 2am production incidents. Types turn "generate plausible code" into "generate code that provably fits."

This flips an old objection on its head. People used to say types slowed them down. In an AI-assisted workflow, types speed you up, because they're the guardrail that lets you accept generated code with confidence instead of auditing every line by hand.

A few habits that compound

If types are this leverage-rich, it's worth writing them with intent rather than appeasing the compiler:

Prefer unions over booleans + optionals. status: "loading" | "error" | "ready" beats three independent boolean flags that can contradict each other.
Name your domain types. type Cents = number documents intent at every use site and lets you tighten it later.
Avoid any; reach for unknown and narrow. any is a hole in exactly the safety net you're paying for.
Let inference work. You don't need to annotate everything — annotate the boundaries (function signatures, exported APIs) and let the rest flow.

The takeaway

TypeScript's real win wasn't catching typos. It was turning your codebase into something with explicit, enforced contracts — and contracts turn out to be exactly what fearless refactoring, reliable tooling, and trustworthy AI assistance all quietly depend on.

We adopted types to prevent a class of bugs. We're keeping them because they're the substrate everything else now builds on. Worth investing in writing them well.

TypeScript Won. Here's What That Actually Bought Us.

Parsa Jiravand — Sat, 27 Jun 2026 07:15:23 +0000

But "won" is the boring part. The interesting part is what types turned out to be good for — which is more, and different, than the original pitch of "catch typos before runtime."

Types are the cheapest documentation you'll never have to update

A function signature is documentation that can't go stale, because the compiler fails the build the moment it lies.

function scheduleReminder(
  userId: string,
  at: Date,
  channel: "email" | "push" | "sms",
): Promise<ReminderId>;

Types make refactoring a mechanical activity instead of an act of courage

The payoff nobody planned: types are the contract AI codegen needs

Here's the part that wasn't in the original sales pitch. The more machine-readable your boundaries are, the more reliably an AI assistant can operate inside them.

A few habits that compound

If types are this leverage-rich, it's worth writing them with intent rather than appeasing the compiler:

Prefer unions over booleans + optionals. status: "loading" | "error" | "ready" beats three independent boolean flags that can contradict each other.
Name your domain types. type Cents = number documents intent at every use site and lets you tighten it later.
Avoid any; reach for unknown and narrow. any is a hole in exactly the safety net you're paying for.
Let inference work. You don't need to annotate everything — annotate the boundaries (function signatures, exported APIs) and let the rest flow.

The takeaway

We adopted types to prevent a class of bugs. We're keeping them because they're the substrate everything else now builds on. Worth investing in writing them well.

Your Design System Is Now an API for Machines

Parsa Jiravand — Fri, 26 Jun 2026 07:29:18 +0000

We've always justified design systems with human reasons: consistency, faster onboarding, fewer one-off buttons. All true. But there's a new reason that quietly outweighs the rest — your design system is becoming the API that machines build UI against.

When an AI assistant generates a screen, the quality of its output is bounded almost entirely by the vocabulary you give it. A loose, undocumented pile of components produces loose, inconsistent output. A tight, well-typed, well-named system produces output that looks like your team wrote it. The design system stops being documentation and becomes a constraint surface.

What "good rails" actually look like

If a model (or a junior dev, honestly — same requirements) is going to compose your components correctly without hand-holding, the system has to be legible from the types and names alone.

Names that describe intent, not appearance.

// Weak: the model has to guess when to use which
<BlueButton />  <SmallButton />  <RoundButton />

// Strong: intent is in the name, variants are props
<Button variant="primary" size="sm" />

Props that make illegal states unrepresentable. If a component can be configured into a broken combination, something will eventually configure it that way. Push the constraints into the type system:

// A toast is either transient (auto-dismiss) OR action-required — never both.
type ToastProps =
  | { kind: "transient"; durationMs: number }
  | { kind: "action"; onAction: () => void; actionLabel: string };

A union like this is worth more than a paragraph of docs, because it's enforced. Neither a human nor a model can pass an onAction to a transient toast.

One obvious way to do each thing. Three different ways to render a modal is three ways to get it subtly wrong. Every redundant path is a fork where generated code can drift from your conventions.

The shift in where you spend effort

Old priority order for a design system:

Visual polish
Documentation / Storybook
Type safety (nice to have)

New priority order:

Type safety and clear contracts — the machine-legible layer
Clear, intent-based naming
Visual polish
Docs (increasingly, the types are the docs)

This isn't because polish stopped mattering — it's because polish is now the cheap part. What's expensive and high-leverage is the part that lets everything built on top be correct by default.

A concrete test

Want to know if your design system is ready for this world? Try this: hand an AI assistant only your component type definitions (no screenshots, no prose) and ask it to build a settings page. Then look at the output.

If it composed sensible, on-brand UI from the types alone — your contracts are doing their job.
If it invented props that don't exist, or reached for raw <div>s and inline styles — that's a map of exactly where your system is ambiguous or incomplete.

That gap is your design-system backlog now. The components it had to fake are the ones missing a clear contract.

The takeaway

Build your design system as if its primary consumer can't see — because increasingly, one of its primary consumers can't. It reads types, names, and constraints, not Figma frames. The systems that thrive in the next few years won't be the prettiest; they'll be the ones whose rules are so clearly encoded that neither a tired engineer at 5pm nor a model at scale can hold them wrong.

A design system used to be a favor you did for your teammates. Now it's the interface your whole org — humans and machines — programs against. Build it like an API, because that's what it is.

The Frontend Is Becoming a Conversation: Where UI Engineering Goes Next

Parsa Jiravand — Thu, 25 Jun 2026 12:39:39 +0000

For a decade, "what's your frontend stack?" was a loaded question. jQuery vs. Backbone. Angular vs. React. Webpack vs. everything. The churn was exhausting, and a non-trivial chunk of our job was just keeping up.

That era is quietly ending — not because we won the framework wars, but because the questions moved up a layer. The interesting problems in frontend today aren't about which library renders a list. They're about how rendering, data, and increasingly generation fit together. And AI is sitting right in the middle of that shift.

The stack consolidated more than we admit

Look at what most new production apps actually reach for in 2026:

React or Svelte/Vue for the component model, with the framework wars settling into "pick one, they're all fine."
A meta-framework — Next, Remix/React Router, SvelteKit, Nuxt — because nobody hand-rolls routing, data loading, and SSR anymore.
TypeScript by default. Not a debate. The plain-JS greenfield project is now the exception.
Server-first rendering (RSC, islands, streaming) as the baseline, with the client bundle treated as a cost to minimize rather than the center of the universe.

The center of gravity moved back toward the server — but a smarter server that streams HTML, hydrates selectively, and treats the network boundary as a first-class design concern. The pendulum didn't swing back to 2010; it spiraled forward.

What AI actually changed (and what it didn't)

The hype says "AI writes the frontend now." The reality on the ground is more specific and more interesting.

It collapsed the cost of the first 80%. Scaffolding a component, wiring a form, translating a Figma frame into JSX, writing the Tailwind for a layout — these used to be hours of work and are now minutes. That's real, and it's already changed how teams estimate.

It did not collapse the last 20%. Accessibility edge cases, focus management, race conditions in async state, the weird Safari bug, the design-system invariant that isn't written down anywhere — this is still where senior engineers earn their keep. AI gets you a plausible draft; it doesn't get you a correct one. The skill that's appreciating in value is judgment: knowing what "done" means and being able to tell when the generated code is subtly wrong.

// AI will happily generate this.
function Price({ cents }: { cents: number }) {
  return <span>${(cents / 100).toFixed(2)}</span>;
}

// It will not, on its own, ask:
//  - What about currencies that aren't cents-based (JPY)?
//  - What locale formats this for the user?
//  - What happens when `cents` is a float from a bad API?
// That question-asking is the job now.

The shift that matters: UI as something you generate, not just write

Here's the genuinely new idea. For years, "server-driven UI" meant the backend sending a layout description that the client renders. AI pushes that further — toward interfaces that are assembled on demand from intent rather than authored ahead of time.

We're not fully there, and a lot of "generative UI" demos are toys. But the direction is clear:

Static UI — you write every screen by hand. (Where we've been.)
Server-driven UI — the backend describes screens; the client renders from a schema.
Generative UI — a model produces the component tree for a given user and context, constrained by your design system.

The teams getting value from #3 today aren't letting a model freestyle pixels. They're giving it a tightly constrained vocabulary — a fixed set of audited components and tokens — and letting it compose within those rails. The design system stops being documentation and becomes the guardrail an AI plans against. That reframes a lot of frontend architecture work: your component API is now also a prompt surface.

What this means for the next couple of years

A few predictions I'd actually bet on:

The component library becomes the most valuable asset on the team — because it's what both humans and models build against. Investment in a clean, well-typed, accessible design system pays off twice.
Types and contracts win. The more machine-readable your boundaries (TS types, schemas, OpenAPI), the more reliably AI can operate inside them. Ambiguity is the enemy of generation.
The job title blurs. "Frontend engineer" increasingly means product engineer who owns the experience end-to-end — data fetching, the rendering strategy, the AI-assisted authoring loop, and the taste to know when it's wrong.
Reviewing replaces typing. The bottleneck shifts from producing code to evaluating it. If you can't read code critically and fast, you'll be slower in an AI world, not faster.

The takeaway

The frontend isn't being automated away — it's being re-leveraged. The mechanical parts are getting cheap, and the parts that were always the actual hard work — architecture, correctness, accessibility, taste — are getting more valuable, not less.

The engineers who thrive won't be the ones who type the fastest or memorize the most APIs. They'll be the ones who can hold a clear picture of what good looks like, express it in constrained, machine-legible building blocks, and tell — instantly — when the draft in front of them is wrong.

The frontend is becoming a conversation. Worth getting good at the half of it that's still yours.

DEV Community: Parsa Jiravand

Your fetch() Is Still Running After the User Left

The race condition hiding in every search box

AbortController in plain terms

The React pattern: cancel in the cleanup function

It's not just for fetch()

What about React Query, SWR, or TanStack?

The takeaway

You reached for !important again. @layer is the real fix.

Why you keep losing the specificity war

One line that changes the currency

The third-party reset problem, gone

The four-layer pattern that fits most apps

The answer trips everyone (and it's the migration path)

The new question in DevTools

So put the !important down

The page transition you pay a library for is now free

One rule. The whole site cross-fades.

The mental model that makes the rest click

The trick worth the price of admission

SPAs get the same engine, behind a function

Adding it can't break anything

Where it fits — and where it doesn't

Back to that library you were about to install

:has() isn't a parent selector. It deletes JavaScript.

Why "parent selector" is the wrong name

The class of JavaScript that just disappears

Three you can paste in today

The one place to slow down

So which JS is still pretending to be CSS?

Your Save button waits 300ms for nothing. Stop it.

What the slow version actually costs

Act first, apologize later

Where manual rollback falls apart

The actions you should never fake

So why does the Save button still wait?

Your card breaks in the sidebar. Here's the real fix.

The question media queries can't answer

One declaration changes the question

When the layout nests, name the container

So is @media dead? No — and here's the line

The bonus you'll notice in Storybook

The fix was one line — and a better question

The URL Is Your Best State Manager

What belongs in the URL

What you gain for free

The pattern in React

The failure mode to watch for

The takeaway

Server Components Without the Hype: A Mental Model That Sticks

The one distinction that matters

Why this is different from SSR

The rules that trip people up (and why they exist)

When to actually reach for it

The takeaway

TypeScript Won. Here's What That Actually Bought Us.

Types are the cheapest documentation you'll never have to update

Types make refactoring a mechanical activity instead of an act of courage

The payoff nobody planned: types are the contract AI codegen needs

A few habits that compound

The takeaway

TypeScript Won. Here's What That Actually Bought Us.

Types are the cheapest documentation you'll never have to update

Types make refactoring a mechanical activity instead of an act of courage

The payoff nobody planned: types are the contract AI codegen needs

A few habits that compound

The takeaway

Your Design System Is Now an API for Machines

What "good rails" actually look like

The shift in where you spend effort

A concrete test

The takeaway

The Frontend Is Becoming a Conversation: Where UI Engineering Goes Next

The stack consolidated more than we admit

What AI actually changed (and what it didn't)

The shift that matters: UI as something you generate, not just write

What this means for the next couple of years

The takeaway

So put the `!important` down

So is `@media` dead? No — and here's the line