Forem: Sam Abaasi

The Trap of Perfectionism: Do Easy Peasy Lemon Squeezy

Sam Abaasi — Sun, 03 May 2026 12:22:21 +0000

I've spent years writing articles — and almost as many years not publishing them.

Not because I had nothing to say. I had everything to say. Every time I solved a hard problem or finally understood something deeply — I wrote it down. That feeling of a light turning on after days of confusion? I wanted to give that to someone else.

But perfectionism had other plans.

Drafts Everywhere

Medium. DEV Community. Google Docs. Chunks of paper stuffed inside books, sitting at the bottom of my laptop bag, falling out when I least expect it.

But I never wanted to publish something incomplete. No article without proper diagrams. No explanation that left gaps. It had to be whole — or it wasn't going out.

So every draft just sat there — waiting for the perfect diagram, the perfect depth of knowledge, the feeling that I truly understood every part of the topic before I had the right to explain any of it.

Three years of "not yet."

What I Was Perfectionist About

Not grammar. Not formatting. Something deeper.

I wanted to make it easy to understand — the kind of explanation where someone finishes and thinks why didn't anyone explain it like this before? I wanted great visualizations that make things clear. I wanted to cover everything so no one gets lost halfway.

Underneath all of that was a quiet fear: the fear of not being good enough. Of not actually helping someone the way they needed.

The Thing Jack Harrington Says

Jack Harrington says it in almost every video:

Easy peasy lemon squeezy.

At some point I actually heard what he was saying — if you understand something well enough, you can make it feel light for someone else. The complexity is real. The explanation doesn't have to be heavy.

And he uses tools. He doesn't spend three days hand-crafting a perfect diagram when ChatGPT can make a clear one in five minutes.

So I started doing the same. And suddenly the wall was gone.

The goal was never to be perfect. It was always that moment — when something clear for someone. A perfect article in a draft helps nobody. An honest one out in the world might change how someone thinks forever.

I Cut the Code. I Kept the Story.

I stopped trying to cover everything. Instead I focused on the problem-solution mindset — don't just show the answer, show the journey. The steps, the wrong turns, how the solution was actually found.

That's how I learn best. Not from clean final answers — from watching someone walk the path. You can see it in my React series: articles that don't just explain how React works, but trace why each piece exists. The journey, not just the destination.

What Finally Got Published

Two series. Many articles. Years of drafts — finally out.

⚛️ How React Works Under the Hood — 9 parts. From why Fiber exists to Server Components and hydration. The series I most wanted to find when I was learning and never could.

🔧 Extending bpmn-io Form-JS Beyond Its Limits — 23 parts. The architecture the official docs never wrote. Everything I had to discover through trial and error — so you don't have to.

The Real Lesson

Wanting clarity, great visuals, and depth — none of that is wrong.

But perfectionism becomes a trap the moment it stops making the work better and starts stopping the work from existing.

So — what's yours? What have you been sitting on because it's just not ready yet?

Easy peasy lemon squeezy — not because it's easy. Because you did the hard work, so the reader doesn't have to do it alone.

Sam Abaasi — Frontend Engineer
Medium · DEV Community · LinkedIn

How React Works (Part 9)? The Complete Picture: From a Keystroke to a Pixel

Sam Abaasi — Sat, 02 May 2026 14:46:35 +0000

The Complete Picture: From a Keystroke to a Pixel

Series: How React Works Under the Hood
This is the final article. If you haven't read Parts 1–8, this article won't land the way it should. Go back and start there.

Part 1: Motivation Behind React Fiber: Time Slicing & Suspense
Part 2: Why React Had to Build Its Own Execution Engine
Part 3: How React Finds What Actually Changed
Part 4: The Idea That Makes Suspense Possible
Part 5: The React Lifecycle From the Inside
Part 6: How State Actually Works
Part 7: The Trap of Vibe Coding useCallback
Part 8: Server Components & Hydration: The Real Story

Eight Articles. One Question.

In Part 1, Dan Abramov stood in front of a room in Iceland and asked:

"With vast differences in computing power and network speed, how do we deliver the best user experience for everyone?"

We've spent eight articles building the answer. But we've never seen all the pieces working together at once. We've seen Fiber explained. The Scheduler explained. The Reconciler. Algebraic effects. Lifecycle. State. Performance. Server Components. Each one in isolation.

This article puts them together. Not as a summary — as a story. One user. One interaction. Every layer of React underneath it.

By the end, you'll see that everything we built across eight articles was always one system.

The User

She opens a product search page on a mid-range Android phone — the kind of device hundreds of millions of people actually use. Her connection is decent but not fast. She's looking for headphones.

She types. She clicks. She adds something to her cart.

From her perspective: the page loads, she types, results appear, she clicks a button, the cart updates. Four seconds of her life.

Underneath those four seconds, every system in this series ran. Let's trace it.

The Page Loads

The request hits the server. This is Part 8's world.

Server Components run — async, directly querying the database. The product catalog, the navigation, the page layout. None of this code ships to her phone. It renders on the server and becomes the RSC payload — a JSON description of the UI that streams to the client in chunks. Her phone gets real HTML almost immediately, not a white screen waiting for JavaScript.

While the HTML is visible, React starts hydration in the background. It walks the server-rendered DOM and matches each node to its Fiber counterpart — attaching event listeners, storing references, making the page interactive. Because React 18 uses the same Lane priority system from Part 3, if she taps something before hydration finishes, React jumps to that boundary first. The rest of the tree waits. Her tap doesn't go ignored.

The page is ready. She types.

She Types "h"

This is where Parts 2, 3, and 6 all meet.

A change event fires. React calls setQuery('h'). Calling setQuery doesn't immediately update anything — it creates an update object, drops it into a global buffer, and marks a trail called childLanes on every ancestor of the search input fiber, all the way to the root. This is how React knows where work is waiting without walking the entire tree.

The Scheduler sees the update. Because this is a user interaction, it's SyncLane — the highest priority. It runs synchronously. The call stack equivalent of "drop everything and handle this."

React walks the Fiber tree following the trail of childLanes. Every branch with childLanes === 0 is skipped instantly — the footer, the recommendations panel, the filters sidebar. React touches only what needs to change. The input updates. The character appears on screen.

That took a few milliseconds. She doesn't notice. She keeps typing.

The Results Need to Update

Here's the problem that Part 1 opened with — still alive, still relevant.

Filtering 10,000 products on every keystroke is expensive. If React treated the results update with the same urgency as the input update, every character she types would block until the filtering finished. The input would lag. The experience would feel broken.

This is exactly Dan's typing + chart demo from 2018. The chart is the results list. It has to update. But it shouldn't block the input.

The fix is startTransition — wrapping the expensive update so React knows it can wait. The input still updates immediately at SyncLane. The results update in the background at TransitionLane, interruptibly:

setQuery(e.target.value);                          // urgent — runs now
startTransition(() => setResults(filter(query)));  // deferrable — runs when free

That's the entire mechanism. startTransition tells React: this update is real but not urgent. Internally, React assigns it a TransitionLane instead of SyncLane. The Scheduler now has two tasks — the keystroke at the top, the results render below it.

The results render begins using the concurrent work loop — the one that checks shouldYield() after every fiber. She types another character. A new SyncLane keystroke arrives. React abandons the results render mid-tree, handles the keystroke — she sees it immediately — then starts the results render again with the new query.

isPending tells you the transition is in progress, so you can show a spinner or dim the old results while new ones load. The old results stay visible until the render completes. She never sees a blank list.

This is the Git metaphor from Part 1 made real: the keystroke is always the hotfix on main. The results render is always the feature branch. React rebases automatically.

What if you can't wrap the setter?

Sometimes the state lives in a child component or a library you don't control. useDeferredValue solves this — it gives you a deferred copy of a value that React renders at lower priority, interruptibly, without you needing to touch the setter:

const deferredQuery = useDeferredValue(query);
// ResultList receives deferredQuery — renders at TransitionLane, same mechanism

The practical rule: use useTransition when you own the setter, useDeferredValue when you own the value but not where it comes from.

React Finds What Changed

She paused typing. The results render runs to completion. This is Part 3.

React walks the ResultList fiber, runs the component function, gets new JSX. The Reconciler compares old to new. Each product has a key prop — its ID. React builds a map of old fibers keyed by product ID. For each new product, it looks up the existing fiber. Found: reuse it, update only what changed. Not found: create it. Products no longer in results: mark for deletion.

React doesn't touch the DOM during any of this. It marks fibers with flags — insert this, update that, delete this — and bubbles those flags up the tree. By the time it reaches the root, every decision about what needs to change is recorded. Nothing has changed in the DOM yet.

The DOM Updates

The Commit phase runs — synchronous, uninterruptible. The two Fiber trees swap. The workInProgress tree becomes current. What was being built in the background is now the source of truth.

DOM operations execute in order: deletions first, then insertions, then updates. Products that disappeared are removed. New products are inserted. Changed cards get their props updated directly on the existing DOM node — no recreation.

The browser paints. She sees the filtered results.

She Clicks "Add to Cart"

The click fires. setCartCount(c => c + 1) is called. Same machinery as the keystroke — SyncLane, update queued, trail marked up to the root, Scheduler fires synchronously.

React walks the trail. Everything outside the Header subtree has childLanes === 0 — the results list, the filters, the footer — all skipped in one check each. React touches only the Header and its CartIcon child.

The render runs. The commit runs. Now Part 5 takes over.

useLayoutEffect fires synchronously — the DOM is updated, the browser hasn't painted yet. If CartIcon needs to measure its width for an animation, this is the only safe moment. Then the browser paints. She sees the cart count increment.

In the next macro task — after paint, via MessageChannel — useEffect runs. The analytics event fires. localStorage syncs. None of this blocked the paint. None of it delayed what she saw.

What Didn't Run

Of the entire component tree — dozens of components, hundreds of fibers — exactly three ran their render functions for the cart click:

The root — has childLanes > 0
Header — has childLanes > 0
CartIcon — the state changed here

Everything else: ResultList, SearchInput, Filters, Footer, Recommendations, every ProductCard — skipped. Not because of React.memo. Not because of useCallback. Because childLanes was zero on every other subtree, and React's built-in bailout skipped each one in a single check.

This is the answer to Part 7. The tools exist for the rare cases where the built-in bailout isn't enough. For everything else — the default behavior handles it.

The Complete Map

Eight parts. One answer.

Fiber is the foundation. React replaced the opaque JavaScript call stack with its own — plain objects it controls completely. This made pausing, resuming, and prioritizing possible. Without Fiber, nothing else in this series exists.

The Scheduler sits on top of Fiber and decides what runs and when. Keystrokes get SyncLane — they always run first, synchronously. Results renders get TransitionLane — they run in the background, interruptibly. shouldYield() checks the clock after every fiber to keep the browser breathing between frames.

The Reconciler uses the Fiber tree to find the minimum set of DOM changes. It follows the childLanes trail to find what changed, skips everything with clean subtrees, diffs lists by key, and marks flags on fibers — never touching the DOM until the entire decision is made. Then the Commit phase applies everything atomically so the user never sees a half-updated UI.

Algebraic Effects is the mental model that connects Suspense, ErrorBoundary, and hooks. Components signal what they need by throwing. React — acting as the effect handler — catches it, decides what to do, and resumes when the data arrives. useState feels local because of this model, even though state lives on a Fiber node React controls.

Lifecycle is when effects run relative to the Commit phase. useLayoutEffect fires synchronously before the browser paints — for DOM measurements that must happen before the user sees anything. useEffect fires after paint in the next macro task — for everything else. The separation isn't arbitrary. It maps directly to the Commit phase structure.

State is a hook object on a Fiber's linked list. Calling setState doesn't update immediately — it drops a note in a queue. React reads that queue during the next render, on its own schedule, in its own order. This is why you see the old value after calling setState. The snapshot hasn't changed yet. The note is pending.

Performance is mostly free. The childLanes bailout skips entire subtrees in one check when nothing changed. Structural patterns like children-as-props prevent unnecessary re-renders without any memoization overhead. React.memo, useCallback, and useMemo exist for the small set of cases where the built-in bailout genuinely isn't enough — and they should only be added after measuring.

Server Components moved the question from "how do we render faster on the client" to "how do we send less to the client in the first place." Server code that never ships. RSC payloads that stream progressively. Selective hydration that prioritizes what the user is interacting with. Every Server Action a public endpoint — treat it like one.

What's Still Being Built

The series ends here but React doesn't.

The React Compiler is stable and shipping. It automatically applies the memoization from Part 7 at build time — React.memo, useMemo, useCallback — applied intelligently, without you writing any of it. Understanding this series is exactly what makes your code Compiler-friendly.

use() is the ergonomic layer on top of the algebraic effects model from Part 4. Where Suspense required a data library to implement the throw-Promise pattern, use() exposes it directly from React.

Server Actions security is still maturing. React2Shell revealed a persistent gap between the mental model (local function) and the reality (public HTTP endpoint). The ecosystem is figuring out better defaults. Until then: validate everything.

The One-Sentence Answer

React delivers the best user experience for everyone by giving developers a declarative component model while handling — invisibly — the complexity of prioritizing work, interrupting expensive renders, deferring non-urgent updates, minimizing DOM changes, and progressively delivering content from server to client, through the Fiber and Scheduler machinery built for exactly this purpose.

Eight articles to earn one sentence.

What You Actually Have Now

Before this series, React was a tool you used. After it, React is a system you understand.

The next time an input lags, you know it's a SyncLane update blocked by a lower-priority render — and you know startTransition is the right fix, not useCallback. The next time a component re-renders unexpectedly, you know to check the reference equality of its props and the childLanes trail — not to wrap everything in React.memo. The next time a page loads slowly, you know the difference between a bundle size problem (Server Components), a data waterfall problem (streaming and Suspense), and a render performance problem (Fiber and Reconciler).

The tools haven't changed. But the questions you ask before reaching for them have.

That's what understanding internals actually gives you: not the ability to contribute to React's source code, but the ability to debug faster, make better decisions earlier, and stop adding complexity to fix problems you only half-understood.

Write something. Ship it. Now you'll know why it works.

🙏 Thank You

This series exists because of the people who built these systems and took the time to explain them.

Dan Abramov — for Beyond React 16, the Git metaphor that makes Time Slicing click, RSC from Scratch, Algebraic Effects for the Rest of Us, and overreacted.io. More teaching in one career than most people manage in ten.

Andrew Clark — for the react-fiber-architecture document that set the design goals every article in this series built toward.

Sebastian Markbåge — for the algebraic effects mental model that connects Suspense, ErrorBoundary, Hooks, and Context into one coherent story.

Matheus Albuquerque — for the clearest explanation of FiberNode internals at React Summit 2022.

Sam Galson — for connecting React to the wider computer science of fibers, coroutines, and continuations.

JSer (jser.dev) — for the deepest source-level analysis of React internals anywhere on the internet. Every code-level claim in this series was verified against JSer's work. An extraordinary resource.

Sophie Alpert, Joe Savona, Luna Wei — for the React team's continued work on documentation, RFCs, and honest discussion of tradeoffs.

Lydia Hallie — for JavaScript visualizations that shaped this series' style from the beginning.

Lachlan Davidson — for responsibly disclosing CVE-2025-55182 and working with the React team to fix it.

That's the series. Thank you for reading. 🔧

Tags: #react #javascript #webdev #tutorial

How React Works (Part 8)? Server Components & Hydration: The Real Story

Sam Abaasi — Sat, 02 May 2026 14:32:09 +0000

Server Components & Hydration: The Real Story

Series: How React Works Under the Hood
Part 1: Motivation Behind React Fiber: Time Slicing & Suspense
Part 2: Why React Had to Build Its Own Execution Engine
Part 3: How React Finds What Actually Changed
Part 4: The Idea That Makes Suspense Possible
Part 5: The React Lifecycle From the Inside
Part 6: How State Actually Works
Part 7: The Trap of Vibe Coding useCallback
Prerequisites: Read Parts 1–7 first.

Where We Left Off

Through Parts 1–7, every problem we solved lived on the client. The call stack couldn't pause — so React built Fiber. Re-rendering was too slow — so React built the Reconciler. State management was confusing — because it's a queue on a Fiber node, not a variable. Performance tools were overused — because developers reached for them before understanding the problem.

Every solution stayed inside the browser. The user's device was the bottleneck. The network was just the delivery mechanism.

Part 8 changes that. Because there's a whole category of problem that no client-side optimization can fix — and it took the React team until 2023 to fully solve it.

The Problem Nobody Talks About

You've shipped a React app. You've done everything right. You memoized where it mattered. You fixed re-renders. You code-split your routes. React DevTools shows a clean profile. Your API is fast.

Then you open Chrome on a mid-range Android phone with a throttled 3G connection — the kind of device hundreds of millions of people actually use — and you watch the screen stay white for four seconds before anything appears.

You look at the Network tab. Before your user sees a single pixel of your app, their phone downloaded, parsed, and executed 380kb of JavaScript. You open the bundle analyzer. Half of that JavaScript is components that render completely static content — a product description that never changes, a nav with hardcoded links, a footer, a terms page. None of them use state. None of them handle events. They just render text and markup.

But they ship to every client. On every load. On every device. Including that phone on 3G that Part 1 opened with.

This is the problem that Part 1's question — "with vast differences in computing power and network speed, how do we deliver the best user experience for everyone?" — still hadn't fully answered by the end of Part 7. We optimized what happens on the client. But we never questioned why so much work was happening on the client in the first place.

The naive fix was server-side rendering. But SSR had a fundamental flaw that took years to properly name — and understanding that flaw is what makes Server Components make sense.

The Problem: The Two-Trip Lie

To understand why Server Components exist, you need to go back to how server rendering worked before them.

Dan Abramov explained the origin story in his RSC from Scratch deep dive by taking you back to 2003. PHP on a server: the server gets a request, reads a file or a database, returns HTML. Simple. The user sees content immediately. No JavaScript bundle to download. No client-side rendering. Just a server doing work and returning a result.

React brought rich interactivity but also a cost: everything runs in the browser. Large bundles. Slow initial loads on slow connections. So the industry added server rendering back — render HTML on the server first, send it to the client, then download JavaScript and "hydrate" the page to make it interactive.

This solved the blank screen problem. But it created what the React team calls a two-trip problem.

The server renders HTML — fast, visible immediately. Then the browser downloads all the JavaScript anyway. React runs again on the client. Re-does the work. Attaches event listeners. Any data fetched on the server to render the HTML? Fetched again on the client. Bundle size? Unchanged — every component that ran on the server also ships to the client. Server work didn't reduce client work. It looked like a performance win but the full cost came later.

This is the problem Server Components actually solve.

What Hydration Actually Is — and What's Wrong With It

Server-side rendering gave React apps faster first paint. But it introduced a problem that almost nobody explained clearly: the page looks ready before it is.

The server renders HTML and sends it. The user sees a complete-looking page — the nav, the content, the buttons. They try to click something. Nothing happens. The button doesn't respond. The form doesn't submit. The dropdown doesn't open. The page looks interactive but it isn't — because React hasn't attached any event listeners yet.

This is the hydration gap. And it exists because of how hydration works.

From jser.dev's hydration internals: hydration is not re-rendering. React does not recreate the DOM. Instead, React walks the existing server-rendered DOM tree in parallel with the Fiber tree it's building, matching each fiber to its corresponding DOM node — storing a reference in fiber.stateNode. Event listeners are attached. The DOM is reused. This is why hydration is faster than a fresh render.

But the entire tree must hydrate before any part becomes interactive. One slow component at the top of the tree blocks the click handlers on a button at the bottom. React walks the tree sequentially, and until that walk is complete, nothing responds.

React 18 fixed this with selective hydration. Using the same Lanes priority system from Part 3, React can now interrupt hydration to handle a user interaction first. If a user clicks a button before hydration reaches it, React jumps to that boundary using SyncLane — hydrates just enough to handle the interaction — then resumes the rest of the tree. The architecture from Part 3 extends directly here: interruptible work, priority-driven, same system.

Streaming takes this further still. Instead of waiting for all data before sending any HTML, the server sends the shell immediately and streams each Suspense boundary as its data resolves. The client starts hydrating what arrived while the rest is still coming. Multiple chunks, progressive — no blank screen waiting for the slowest database query.

But even with selective hydration and streaming, there's still a cost that SSR never eliminated. The JavaScript still ships. Every component still runs on the client. That's the problem Server Components solve.

What Server Components Actually Are

From the React Labs March 2023 blog post, written by the React team:

"We are introducing a new kind of component — Server Components — that run ahead of time and are excluded from your JavaScript bundle. Server Components can run during the build, letting you read from the filesystem or fetch static content. They can also run on the server, letting you access your data layer without having to build an API."

Server Components run only on the server. Their code never ships to the client. Client Components — marked explicitly with 'use client' — run on the client as before. The boundary between them is a decision you make explicitly at every component.

The critical constraint the boundary enforces: functions cannot cross from Server to Client. Functions aren't serializable. If you try to pass a function as a prop from a Server Component to a Client Component, React throws an error. Only plain serializable values can cross — strings, numbers, objects, arrays, React elements. This shapes every RSC architecture decision. It's why you can't pass event handlers from the server side.

What the server sends is not HTML and not JavaScript. It's the RSC payload — a JSON-like description of the rendered UI tree. Here's what a simple RSC payload actually looks like in practice:

J0:["$","div",null,{"className":"post"}]
J1:["$","h1",null,{"children":"Hello World"}]
J2:["$","p",null,{"children":"Content here"}]

Each line is a serialized React element — type, key, ref, props. React on the client reads this and builds or updates its Fiber tree from it. As Dan's RSC from Scratch describes: "a production-ready RSC setup sends JSX chunks as they're being produced instead of a single large blob at the end. When React loads, hydration can start immediately — React starts traversing the tree using the JSX chunks that are already available."

For Client Components, only their props get serialized into the payload — not their code, which stays in the bundle. The payload contains a reference to the Client Component (a module ID the bundler knows about) plus the props to render it with.

This is why RSC works with client-side navigation: navigating to a new page in a Next.js App Router app doesn't reload the whole page. It fetches a new RSC payload and React merges it into the existing Fiber tree — same mechanism, different data.

The React docs explain this model clearly — the boundary rules, how composition works, how to think about what goes where. It's genuinely good documentation.

What the docs didn't prepare developers for: the mental model they encourage — writing async function submitOrder() marked 'use server' and calling it like any local function — is exactly the mental model that skips the input validation you'd never skip on an API route. In December 2025, that gap cost real companies their servers.

The Security Reality: React2Shell

On November 29th, 2025, security researcher Lachlan Davidson reported a vulnerability to Meta's Bug Bounty program. Four days later, the React team disclosed it publicly.

From the official React blog post:

"There is an unauthenticated remote code execution vulnerability in React Server Components."

CVE-2025-55182 — CVSS 10.0.

The root cause: React Server Functions (Server Actions) allow a client to call a function on the server. React translates the client's request into an HTTP request, which the server deserializes and executes. The deserialization process did not properly validate inputs. An attacker could craft a malicious HTTP request that, when deserialized by React, achieved remote code execution on the server — with no authentication required, against any app using React Server Components.

The React blog was direct: "Even if your app does not implement any React Server Function endpoints it may still be vulnerable if your app supports React Server Components."

Exploits appeared within 24 hours of disclosure. Unit 42 at Palo Alto Networks documented post-exploitation activity including reverse shells, malware installation, and activity linked to state-sponsored threat actors.

Two follow-on CVEs were disclosed days later: source code exposure (CVE-2025-55183 — a crafted request could cause the server to return its own source code) and denial of service (CVE-2025-55184 — a crafted request caused an infinite loop that hung the server process permanently). The initial fix for the DoS was incomplete, requiring a second patch under CVE-2025-67779. A fourth vulnerability was disclosed in January 2026 (CVE-2026-23864).

What this means for you as a developer:

Every Server Action ('use server' function) is a public HTTP endpoint. Anyone on the internet can send a POST request to it — not just your frontend. There is no framework magic that makes inputs safe by default. You must validate and sanitize every argument exactly as you would validate input to an Express route handler or an API endpoint.

The mistake RSC encourages is writing server-side logic that feels like an internal function — you're just calling submitForm() from a button click, it looks local. But it's an HTTP endpoint. Untrusted input. Treat it that way.

Additionally: whatever you pass as props from a Server Component to a Client Component travels in the RSC payload — visible in the browser's network tab. Pass only what the client needs to render. Passing an entire database row when only a name is needed exposes the rest of that data to anyone watching the network response.

A Concrete Trace: What Actually Happens on Navigation

Let's make this real. When a user clicks a link in a Next.js App Router app:

User clicks a link. React intercepts the navigation. Instead of a full page reload, it fetches the RSC payload for the new route from the server.

Server processes the request. Server Components for the new route run — async, querying databases, reading files. They render to the RSC payload format. Client Component boundaries are replaced with module references plus serialized props.

Payload streams to the client. The response arrives in chunks. React starts processing chunks as they arrive — it doesn't wait for the complete response.

React merges the payload into the Fiber tree. For unchanged parts (shared layout, nav), React skips re-rendering entirely. For new content, React creates or updates fibers from the payload. Client Components receive their serialized props and render on the client.

The page updates. No full reload. No loss of client-side state. The URL changes. The content changes. Client Components that were already hydrated stay hydrated.

This is the genuine architectural win: the server does the data work, the client does the interaction work, and the payload is the bridge between them.

The Vibe Coding RSC Trap

In Part 7 we saw what happens when developers add useCallback and React.memo everywhere without measuring — code that's harder to read, harder to debug, and often slower than before.

The same pattern exists with Server Components. You read the Next.js App Router docs. You migrate your pages directory. You follow the examples. And you end up writing code like this:

// Every component that uses state or events gets 'use client'
'use client';
export function Header() { ... }

'use client';
export function SearchInput() { ... }

'use client';
export function ProductCard() { ... }

'use client';
export function Footer() { ... } // doesn't even use state — added just in case

Every component is a Client Component. Every component ships JavaScript to the client. The RSC architecture is in place — the routing, the layout, the page files — but the actual benefit (JavaScript that never ships) is zero. You've added the complexity of the Server/Client boundary, the mental overhead of 'use client' everywhere, and the security surface of Server Actions — for a bundle size identical to before.

This happens because the docs show you the mechanics but not the principle. The principle is simple: a component should only be a Client Component if it genuinely needs the client — state, effects, browser APIs, event handlers. Everything else can be a Server Component. A product description that just renders text? Server Component. A nav with static links? Server Component. A footer? Server Component. The question to ask for every component is: does this need to run in the browser?

The vibe coding version asks: does the tutorial mark this as 'use client'? If yes, add it. If the app breaks, add more. This produces an RSC app that costs more than the original — in complexity, in security surface, in developer confusion — and delivers nothing.

When You Don't Need Server Components

Dan Abramov and Joe Savona discussed the honest tradeoffs of RSC in their live stream with Kent C. Dodds. The team has never claimed RSC is the right tool for every app.

If your app is mostly interactive — drawing tools, real-time editors, complex forms — it consists almost entirely of Client Components anyway. RSC adds architectural complexity for minimal gain. If your API and frontend run in the same region, the round-trip savings from server-side fetching are negligible. The complexity isn't justified by the performance return.

The more important consideration is team understanding. The React2Shell vulnerability was possible because the boundary between trusted server code and untrusted client input was blurry in the mental model. A team that treats Server Actions as internal functions will skip input validation — and that's not a performance problem, it's a critical security bug.

And if you're adopting RSC because it's what the new Next.js docs show, stop and ask what problem you're solving. The React Labs blog post frames RSC as combining the simple request/response model of multi-page apps with the interactivity of single-page apps. That's a genuine win for content-heavy apps with complex data requirements. For a CRUD app with a fast API and a small bundle, you may be adding architectural weight to solve a problem you don't have.

Measure the actual loading problem first. Understand the tradeoff. Then decide.

The One-Sentence Rule

Use Server Components when you have a measured loading problem caused by JavaScript bundle size or data waterfalls — and your team treats every Server Action as a public HTTP endpoint that requires the same validation discipline as any API route. In every other case, measure the problem first.

What's Coming in Part 9

Part 9 is the last article in the series. It answers the question Part 1 opened with: "With vast differences in computing power and network speed, how do we deliver the best user experience for everyone?" — pulling every piece of the series together into one complete picture.

🎬 Watch These

Dan Abramov — RSC from Scratch (GitHub Discussion)
The canonical technical deep dive — inventing RSC from first principles. The RSC payload format and the streaming architecture described in this article come directly from this document.

Dan Abramov + Joe Savona — RSC Live Stream with Kent C. Dodds
Honest discussion of RSC tradeoffs, limitations, and the mental model shift required. The source for the "when you don't need RSC" framing.

JSer (jser.dev) — How basic hydration works internally in React?
The tryToClaimNextHydratableInstance, fiber.stateNode matching, and cursor-based DOM walking described in this article.

JSer (jser.dev) — What is Progressive Hydration and how does it work internally?
Streaming HTML in chunks, Suspense comment node markers (, ), and the retry callback mechanism.

🙏 Sources & Thanks

Dan Abramov — RSC from Scratch (Part 1) written by @gaearon on the reactwg GitHub. The PHP origin story, the RSC payload format, the streaming architecture, and the quote about JSX chunks all come directly from this document.
The React Team — React Labs: March 2023 — the official Server Components definition quoted directly. Critical Security Vulnerability in React Server Components — the official React2Shell disclosure, the vulnerability overview, and the timeline all come from the react.dev blog post.
Lachlan Davidson — for discovering and responsibly reporting CVE-2025-55182 to Meta's Bug Bounty program.
jser.dev — the hydration mechanics (tryToClaimNextHydratableInstance, nextHydratableInstance cursor, fiber-to-DOM matching, selective hydration with Lanes priority, streaming with comment node markers) all come from JSer's source-level analysis: How basic hydration works, How hydration works with Suspense, What is Progressive Hydration, and My guess at how RSC works.
Unit 42 / Palo Alto Networks — for the post-exploitation analysis of CVE-2025-55182 documenting real-world attack patterns.
Dan Abramov + Joe Savona — RSC Live Stream with Kent C. Dodds — for the honest discussion of RSC tradeoffs that informed the "when you don't need it" section.

Part 9 is the final article — the full picture, from Part 1's question to the complete answer. 🔧

Tags: #react #javascript #webdev #tutorial #security

How React Works (Part 7)? The Trap of Vibe Coding `useCallback`

Sam Abaasi — Sat, 02 May 2026 14:15:49 +0000

The Trap of Vibe Coding `useCallback`

Series: How React Works Under the Hood
Part 1: Motivation Behind React Fiber: Time Slicing & Suspense
Part 2: Why React Had to Build Its Own Execution Engine
Part 3: How React Finds What Actually Changed
Part 4: The Idea That Makes Suspense Possible
Part 5: The React Lifecycle From the Inside
Part 6: How State Actually Works
Prerequisites: Read Parts 1–6 first — especially Parts 3 and 6.

Where We Left Off

In Part 6 we saw how useState works — state stored on the Fiber as a hook object, updates queued and processed on the next render, the component function running fresh from the top every time. Every render. From the top.

That last part is what this article is about. Because every render from the top means every value inside the component is recreated. And that single fact is the root cause of most React performance problems — and the reason the most common advice for fixing them often makes things worse.

You Wrapped Everything in `useCallback`. You Added `React.memo` to Every Component. Your App Is Still Slow. What Went Wrong?

This is the scene. You open the React DevTools Profiler. Components are re-rendering on every interaction. You've read the articles. You know the tools. So you do what everyone does:

function SearchPage() {
  const [query, setQuery] = useState('');
  const [filters, setFilters] = useState({});

  const handleSearch = useCallback(() => search(query), [query]);
  const handleFilter = useCallback((key, val) => setFilters(f => ({...f, [key]: val})), []);
  const handleReset = useCallback(() => setFilters({}), []);
  const handleExport = useCallback(() => exportResults(query, filters), [query, filters]);

  const activeFilters = useMemo(
    () => Object.entries(filters).filter(([_, v]) => v),
    [filters]
  );

  return (
    <ResultList
      onSearch={handleSearch}
      onFilter={handleFilter}
      onReset={handleReset}
      onExport={handleExport}
      activeFilters={activeFilters}
    />
  );
}

const ResultList = React.memo(({ onSearch, onFilter, onReset, onExport, activeFilters }) => {
  // ...
});

You deploy. You open the Profiler again. ResultList is still re-rendering. Some interactions are slower than before.

What went wrong?

This article answers that — from the inside out.

React's Default: Re-render Everything, Skip What It Can

React's mental model has always been simple: when state changes, re-render. Not just the component that changed — all of its children too.

But React has a built-in bailout system we covered in Part 3. When React walks down to a child, it checks one thing before running it:

Are the props the same object reference as last render?

If yes — same reference, not just same values — React skips that component entirely. The child doesn't run. Its children don't run. The entire subtree is skipped in one check. Free, automatic, no tools required.

The problem: in practice, props almost always get new references on every render — even when the values inside them are identical. And this is the root cause of most React performance problems.

Every Render Creates New References Without You Noticing

When a parent component re-renders, it runs its function from the top. Every line executes again:

function SearchPage() {
  const [query, setQuery] = useState('');

  // ❌ New function object on every render
  const handleSearch = () => search(query);

  // ❌ New object on every render
  const style = { color: 'red', padding: '8px' };

  // ❌ New array on every render
  const results = data.filter(item => item.active);

  return <ResultList onSearch={handleSearch} style={style} results={results} />;
}

Every render, handleSearch is a brand new function. style is a brand new object. results is a brand new array. They look identical — same values, same contents — but they're different objects in memory.

React's bailout uses === reference equality. Old handleSearch !== new handleSearch. So React can't bail out, and ResultList re-renders on every keystroke in the search input — even when the results haven't changed.

The Part Nobody Tells You: Children Re-render Even With No Props

Here's the insight from jser.dev's bailout article that most performance guides miss entirely.

Given this structure:

function SearchPage() {
  const [query, setQuery] = useState('');

  return (
    <div>
      <input value={query} onChange={e => setQuery(e.target.value)} />
      <ResultList />  {/* no props at all */}
    </div>
  );
}

When the user types and SearchPage re-renders, ResultList re-renders too — even though it receives zero props.

Why? Because when SearchPage's function runs, it creates a new React element for <ResultList />. That element object is new. When React's reconciler compares the old pendingProps to the new pendingProps on the ResultList fiber, they're different objects. So React re-renders ResultList. The issue isn't the prop values — it's where the element is created.

This means React.memo on ResultList alone doesn't help here at all.

The Free Fix: Children as Props

This is the most underused performance pattern in React. Zero memoization. Zero dependency arrays. Just a structural change.

// ❌ Before — ResultList re-renders whenever SearchPage re-renders
function SearchPage() {
  const [query, setQuery] = useState('');
  return (
    <div>
      <input value={query} onChange={e => setQuery(e.target.value)} />
      <ResultList />
    </div>
  );
}

// ✅ After — ResultList never re-renders when query changes
function App() {
  return (
    <SearchPage>
      <ResultList />
    </SearchPage>
  );
}

function SearchPage({ children }) {
  const [query, setQuery] = useState('');
  return (
    <div>
      <input value={query} onChange={e => setQuery(e.target.value)} />
      {children}
    </div>
  );
}

Why does this work? The <ResultList /> element is now created inside App, not inside SearchPage. When SearchPage's state changes, App doesn't re-render. The children prop that SearchPage receives is the same object reference as before. React's built-in bailout kicks in — same reference, skip ResultList.

No React.memo. No useCallback. No overhead. Just structure.

The React docs state this directly: "When a component visually wraps other components, let it accept JSX as children. This way, when the wrapper component updates its own state, React knows that its children don't need to re-render."

Always try structural fixes before reaching for memoization tools. They're free and they don't break.

When You Actually Need `React.memo`

Sometimes the structural fix isn't possible. The child genuinely needs to be defined inside the parent and receive real props. That's when React.memo enters.

React.memo wraps your component in a MemoComponent fiber. Instead of checking reference equality on the whole props object, React runs shallowEqual — comparing each individual prop value:

const ResultList = React.memo(({ results, onSearch }) => {
  return <div>{results.map(r => <Result key={r.id} data={r} />)}</div>;
});

If results and onSearch have the same values as last time, React bails out. Even if the props object itself is new.

One internal detail worth knowing: when you wrap a simple function component with no custom compare function and no defaultProps, React silently upgrades the fiber tag from MemoComponent to SimpleMemoComponent — a faster internal optimization path. Add a custom compare function and you lose this fast path.

But React.memo alone almost never works. If any prop is a function or object created inline during render, shallowEqual fails on that prop — new reference every time. React.memo bails out on nothing.

This is why in the opening example, ResultList still re-renders even though it's wrapped in React.memo. handleSearch, handleFilter, handleReset, handleExport — all created inline, all new references every render. React.memo sees four changed props and re-renders anyway.

What `useCallback` and `useMemo` Actually Do — From the Source

useCallback and useMemo exist for one reason: to stabilize references so React.memo can do its job.

Here's the actual source code for both hooks — mountMemo on initial render and updateMemo on re-render:

// From React source — initial render
function mountMemo(nextCreate, deps) {
  const hook = mountWorkInProgressHook(); // create hook in linked list
  const nextDeps = deps === undefined ? null : deps;
  const nextValue = nextCreate();          // run the factory fn
  hook.memoizedState = [nextValue, nextDeps]; // store [value, deps]
  return nextValue;
}

// From React source — every re-render
function updateMemo(nextCreate, deps) {
  const hook = updateWorkInProgressHook(); // walk to this hook in linked list
  const nextDeps = deps === undefined ? null : deps;
  const prevState = hook.memoizedState;   // [prevValue, prevDeps]

  if (prevState !== null && nextDeps !== null) {
    const prevDeps = prevState[1];
    if (areHookInputsEqual(nextDeps, prevDeps)) {
      return prevState[0];               // deps unchanged → return cached value
    }
  }

  const nextValue = nextCreate();         // deps changed → recompute
  hook.memoizedState = [nextValue, nextDeps];
  return nextValue;
}

updateCallback is identical — the only difference is it stores the function itself instead of calling it.

The dependency comparison runs through areHookInputsEqual:

// From React source — runs on every render for every hook
function areHookInputsEqual(nextDeps, prevDeps) {
  for (let i = 0; i < prevDeps.length && i < nextDeps.length; i++) {
    if (Object.is(nextDeps[i], prevDeps[i])) {
      continue;
    }
    return false; // one mismatch → recompute
  }
  return true;
}

This loop runs on every render, for every hook, for every dependency. It doesn't matter whether deps changed or not — the loop always runs.

The Hidden Cost: What Happens on Every Render

This is what the articles don't tell you.

Even when dependencies haven't changed and useCallback/useMemo return the cached value, React still does this on every render:

Walks to this hook in the linked list — updateWorkInProgressHook() traverses the hook chain every time
Reads hook.memoizedState — accesses [prevValue, prevDeps] from memory
Runs areHookInputsEqual — loops through every dependency with Object.is
Allocates a new function (for useCallback) — React receives the new () => fn you wrote, then decides whether to discard it

That last point surprises most developers. When you write:

const handleSearch = useCallback(() => search(query), [query]);

JavaScript creates the arrow function () => search(query) before calling useCallback. React receives it, runs areHookInputsEqual, and if deps haven't changed, discards the new function and returns the old one. The allocation happened regardless.

So useCallback(fn, [a, b, c]) with unchanged deps on every render means: one function allocation (discarded), three Object.is comparisons, one linked list traversal. For a component that re-renders 50 times per second during a scroll, that's 150 comparisons per second — for a component that might have been fast to render in 0.1ms anyway.

The Vibe Coding Trap

Here's what actually happens in most codebases.

Someone reads that useCallback prevents re-renders. They add it to every function. They add React.memo to every component. They add useMemo to every derived value. "Just to be safe." Copy-paste from the last project. Vibe coding.

// Real pattern from real codebases
function ProfileCard({ userId }) {
  const handleMouseEnter = useCallback(() => setHovered(true), []);
  const handleMouseLeave = useCallback(() => setHovered(false), []);
  const handleFocus = useCallback(() => setFocused(true), []);
  const handleBlur = useCallback(() => setFocused(false), []);
  const containerClass = useMemo(
    () => `card ${hovered ? 'card--hovered' : ''} ${focused ? 'card--focused' : ''}`,
    [hovered, focused]
  );

  return (
    <div
      className={containerClass}
      onMouseEnter={handleMouseEnter}
      onMouseLeave={handleMouseLeave}
      onFocus={handleFocus}
      onBlur={handleBlur}
    >
      <UserAvatar userId={userId} />
    </div>
  );
}

This is a card component. It renders in under 0.1ms. Nothing inside it is expensive. UserAvatar doesn't receive any of the memoized values. The containerClass string is trivially fast to compute.

Every single useCallback and useMemo here adds overhead — dependency comparisons, hook traversals, function allocations — for zero performance benefit. The component was never the bottleneck.

And the real cost shows up in debugging. When containerClass produces the wrong value, you now have to trace through useMemo and its [hovered, focused] deps to understand why. When handleFocus behaves unexpectedly, you check the useCallback closure. What was a simple state bug becomes a memoization debugging session.

The React docs are direct about this: "There is no significant harm to doing that either, so some teams choose to not think about individual cases, and memoize as much as possible. The downside of this approach is that code becomes less readable. Also, not all memoization is effective: a single value that's 'always new' is enough to break memoization for an entire component."

The Right Order

Here's the order that actually fixes performance problems:

1. Measure first. Open React DevTools Profiler. Record a session. Find the component that's actually slow — its render time, how often it renders, and why. Don't optimize what you haven't measured. Most of the time the bottleneck is not where you think it is.

2. Fix the structure. Can the slow child's element be created in a parent that doesn't re-render? Can state be moved down closer to where it's used? Can you use the children-as-props pattern? These fixes are free — no memoization overhead, no stale closure risk, no dependency arrays to maintain.

3. Memoize if structure can't fix it. If structural fixes aren't possible and the component is genuinely expensive to render and receives props that could be stable — then reach for React.memo + useCallback/useMemo together. All three are needed. React.memo without stable references does nothing. useCallback without React.memo on the child does nothing.

4. Verify it worked. Re-run the Profiler. Confirm the component no longer re-renders unnecessarily. If it still does, find what reference is still unstable and trace it back.

The rule, in one sentence: don't add memoization until you have a specific, measured component that re-renders too often, with expensive renders, and props that can be stabilized.

A Note on the React Compiler

The React Compiler (previously React Forget) is now stable. It's a build-time Babel plugin that automatically applies memoization where it's safe — analyzing your components, inferring dependencies, and inserting optimizations without you writing any of it.

But it only works on components that follow the Rules of React: pure renders, no prop mutation, no non-deterministic values during render. Code that follows these rules gets automatic optimization. Code that doesn't gets de-opted — the Compiler falls back and does nothing.

Here's the important point: understanding everything in this article — why references matter, why structural fixes come first, why useCallback has a cost — is exactly what you need to write code the Compiler can optimize. The Compiler doesn't replace understanding React's rendering model. It rewards you for having it.

What's Coming in Part 8

In Part 8 we go into Server Components and Hydration — how React renders on the server, streams the result to the client, and hands off interactivity without re-doing all the work. The rendering model we've built throughout this series extends to the server in some surprising ways.

🎬 Watch These

JSer (jser.dev) — How does React bailout work in reconciliation?
The source for the "children re-render even with no props" insight and the children-as-props bailout pattern. The demo shows exactly which components re-render and why.

JSer (jser.dev) — How does React.memo() work internally?
The MemoComponent vs SimpleMemoComponent internal distinction and shallowEqual — the source for the React.memo internals section.

🙏 Sources & Thanks

jser.dev — the "children re-render even with no props" insight and the children-as-props bailout technique come directly from How does React bailout work?. The MemoComponent/SimpleMemoComponent distinction from How does React.memo() work internally?
React source — mountMemo, updateMemo, mountCallback, updateCallback, and areHookInputsEqual are taken directly from packages/react-reconciler/src/ReactFiberHooks.js in the facebook/react repo. Verified via multiple source walkthroughs.
React docs — the children-as-props principle and the "not all memoization is effective" quote come directly from react.dev/reference/react/memo. The React Compiler section draws from react.dev/learn/react-compiler.
Lydia Hallie — for JavaScript visualizations that shaped this series' style.

Part 8 is next — Server Components and Hydration: how React moved rendering to the server without breaking the client model. 🔧

Tags: #react #javascript #webdev #performance #tutorial

How React Works (Part 6)? How State Actually Works: useState from the Inside

Sam Abaasi — Sat, 02 May 2026 13:59:40 +0000

How State Actually Works: useState from the Inside

Series: How React Works Under the Hood
Part 1: Motivation Behind React Fiber: Time Slicing & Suspense
Part 2: Why React Had to Build Its Own Execution Engine
Part 3: How React Finds What Actually Changed
Part 4: The Idea That Makes Suspense Possible
Part 5: The React Lifecycle From the Inside
Prerequisites: Read Parts 1–5 first.

Three Things That Confuse Almost Everyone

Here are three behaviors of useState that trip up developers at every level:

function Counter() {
  const [count, setCount] = useState(0);

  function handleClick() {
    setCount(count + 1);
    setCount(count + 1);
    setCount(count + 1);
    // You might expect count to become 3
    // It becomes 1
  }

  function handleLog() {
    setCount(count + 1);
    console.log(count);
    // You might expect to see the new value
    // You see the old value
  }

  function handleSame() {
    setCount(count); // setting same value
    // You might expect no re-render
    // Sometimes React still re-renders once
  }
}

All three behaviors make complete sense once you understand how useState actually works under the hood. This article explains all three — and by the end, you'll never be surprised by state again.

Where State Lives

The most important question to start with: when you call useState(0), where does that 0 actually live?

Not in the component function. Component functions are just regular JavaScript functions — they have no persistent memory between calls. Every time React re-renders your component, it calls the function fresh from the top.

State lives on the Fiber. Specifically, on a hook object stored in the fiber's memoizedState field.

Every hook call creates a new hook object and appends it to a linked list hanging off the fiber:

Counter fiber
  └─ memoizedState → hook (useState count)
                       └─ next → hook (useEffect)
                                   └─ next → hook (useRef)
                                               └─ next → null

Each hook object stores the current state value in its own memoizedState field, plus an updateQueue for pending updates, plus a link to the next hook.

This is why the rules of hooks exist — specifically why you can't call hooks conditionally. React doesn't track hooks by name. It tracks them by position in the linked list. Call number 1 is always useState count, call number 2 is always useEffect, and so on. If you skip a hook call with an if statement, every subsequent hook gets the wrong state from the wrong position.

What Happens When You Call `setState`

Here's what most developers picture when they call setCount(count + 1):

React updates the count, then re-renders the component.

Here's what actually happens:

React creates a small update object and adds it to a queue. Then it schedules a re-render for later. The component function does not run again right now.

That's it. Calling setState is not synchronous. It's not instant. It's closer to leaving a note — "please re-render this component with this new value when you get a chance."

From jser.dev's useState article, here is the actual sequence:

Step 1 — Create an update object. React packages your new value (or updater function) into a small object that also carries the current priority lane.

Step 2 — Stash it in a queue. The update goes into a global buffer (concurrentQueues). It's not attached to the fiber yet — React is potentially in the middle of rendering something else and can't safely modify the fiber tree right now.

Step 3 — Schedule a re-render. React calls scheduleUpdateOnFiber, which walks up to the root, marks the trail of childLanes, and registers a task with the Scheduler (from Part 2). The Scheduler will call back to run the render.

Step 4 — At the start of the next render, attach updates. Before the render begins, finishQueueingConcurrentUpdates runs and attaches all stashed updates from the global buffer to their respective fibers' queues. Now the fiber is ready to process them.

Step 5 — During render, process the queue. When React processes the Counter fiber, it reads hook.queue, processes the pending updates in order, and the result becomes the new hook.memoizedState — the new value that useState will return for this render.

A Concrete Trace: One Button Click

Let's make this real. The Counter from the opening — count starts at 0, user clicks the button:

The click happens. The browser fires a click event. React's synthetic event handler calls your handleClick, which calls setCount(count + 1) — that's setCount(1).

dispatchSetState runs. React creates an update object { action: 1, lane: SyncLane } and pushes it into the global concurrentQueues buffer. The Counter fiber is unchanged — it still has hook.memoizedState = 0. The component function has not run again yet.

scheduleUpdateOnFiber runs. React walks up from the Counter fiber to the root, marking childLanes on every ancestor. The Scheduler registers a task to call performConcurrentWorkOnRoot.

The event handler finishes. React checks for other queued updates — there are none. Since this was a user interaction (SyncLane), React runs the render synchronously rather than waiting for the next macro task.

finishQueueingConcurrentUpdates runs. The pending update is moved from the global buffer and attached to hook.queue.pending on the Counter fiber. The fiber is now ready.

React renders the Counter fiber. updateState reads hook.queue, finds the pending update { action: 1 }, runs it through basicStateReducer, and gets 1. This becomes the new hook.memoizedState. The component function runs with count = 1 and returns new JSX.

Commit phase. React finds the changed text node and updates button.textContent to "click 1". The DOM reflects the new state.

Total time from click to DOM update: a few milliseconds. Total re-renders: exactly one.

Why You See the Old Value After `setState`

Now the first confusion makes sense.

setCount(count + 1);
console.log(count); // still the old value

Calling setCount didn't change count. It created an update object and scheduled a re-render. The variable count is a local variable in the current function call — it was captured when the component rendered and it will never change during this render. The new value only exists after the next render completes and useState reads from the processed queue.

This is a fundamental property of React's model: state values are snapshots. Every render captures its own version of state, and that snapshot is frozen for the duration of that render.

Why Three `setCount` Calls Only Increment Once

setCount(count + 1);
setCount(count + 1);
setCount(count + 1);
// count goes from 0 to 1, not 0 to 3

Each of these three calls captures the same count — the snapshot from the current render, which is 0. So all three are equivalent to setCount(0 + 1). React queues three updates, all with value 1. When it processes them in the next render, the result is 1.

The fix is the updater function form:

setCount(c => c + 1);
setCount(c => c + 1);
setCount(c => c + 1);
// count goes from 0 to 3

When you pass a function, React processes the updates in sequence — each one receives the result of the previous. The queue runs 0 → 1 → 2 → 3. The updater function form is specifically designed for when you need to chain updates.

Why Multiple `setState` Calls Don't Cause Multiple Re-renders

This is batching — and it's one of React's most important performance features.

When you call setState multiple times in the same event handler, React doesn't re-render after each call. It collects all the updates, then does a single re-render at the end.

function handleClick() {
  setCount(c => c + 1);  // queued
  setName('Alice');       // queued
  setLoading(false);      // queued
  // → one re-render, not three
}

From jser.dev's useState article: updates are stashed in the global concurrentQueues buffer and only attached to fibers at the beginning of the next render via finishQueueingConcurrentUpdates. This means all three setState calls during the same event handler land in the queue before any render begins — React processes them all in one pass.

Before React 18, batching only happened inside React event handlers. In setTimeout, fetch callbacks, or native event handlers, each setState would trigger a separate re-render. React 18 introduced automatic batching — batching now happens everywhere by default, regardless of where the update originates.

The Same-Value Optimization (and Its Catch)

What happens when you call setState with the same value the state already has?

setCount(count); // count is already 5, setting it to 5 again

React tries to skip the re-render entirely. From jser.dev's article: before scheduling the re-render, dispatchSetState eagerly computes the new state and compares it to the current state using Object.is. If they're identical, React calls enqueueConcurrentHookUpdateAndEagerlyBailout and returns immediately — no render is scheduled.

But here's the catch from jser.dev: this bailout only happens when the fiber's update queue is currently empty. If there's other pending work on the component, React can't safely apply this optimization and may still re-render once. The comment in the React source code says "React tries to avoid scheduling re-render with best effort, but no guarantee."

So the rule in practice: setting state to the same value usually prevents a re-render, but not always. Don't write code that depends on this optimization for correctness.

`useRef`: State Without Re-renders

Now that you understand how useState works, useRef becomes obvious.

useRef is implemented almost identically to useState — it creates a hook object on the fiber's linked list, stores its value in memoizedState. The difference: updating a ref doesn't create an update object and doesn't call scheduleUpdateOnFiber. It just mutates the current property of the ref object directly.

const ref = useRef(0);
ref.current = 1; // direct mutation — no queue, no schedule, no re-render

Because React never learns about the change, it never re-renders. The new value is available immediately (no snapshot problem), but React won't react to it. This makes useRef perfect for values that need to persist across renders without triggering them — timer IDs, previous values, DOM node references.

The tradeoff is exactly what you'd expect: refs are live, mutable, immediate — but invisible to React's rendering system.

The Full Picture

useState is not a magical React primitive. It's a hook object on a linked list on a fiber, with a queue for pending updates and a scheduler that processes them. Every behavior that seems surprising becomes logical once you see the structure:

The snapshot problem exists because state is stored on the fiber, not in a mutable variable — and the fiber gets its new value only after the render processes the queue. The batching behavior exists because updates go into a global buffer before being attached to fibers. The same-value optimization exists because React checks eagerly before scheduling. And useRef is simply the same structure without the scheduling step.

State in React is not instant, synchronous, or mutable in the traditional sense. It's a description of what the next render should look like — and React processes that description on its own schedule, in its own order, using the Fiber and Scheduler machinery from Parts 2 and 3.

What's Coming in Part 7

In Part 7 we look at performance — not the solutions first, but the problems. What actually causes unnecessary re-renders? Why does passing a new object as a prop matter? When is React doing work it doesn't need to? Understanding the problems clearly is what makes React.memo, useMemo, and useCallback make sense — rather than things you add until the lag goes away.

🎬 Watch These

JSer (jser.dev) — How does useState() work internally in React?
The primary source for this entire article — mountState, dispatchSetState, concurrentQueues, finishQueueingConcurrentUpdates, the eager bailout, and the batching mechanism. All sourced from here.

JSer (jser.dev) — How does React re-render internally?
How the update queue is processed during the render phase — the other half of the state story.

🙏 Sources & Thanks

jser.dev — every mechanism in this article comes from JSer's source-level analysis of useState. The mountState flow, dispatchSetState internals, concurrentQueues global buffer, finishQueueingConcurrentUpdates, the eager same-value bailout with the "best effort, no guarantee" caveat, and the batching explanation all come directly from How does useState() work internally in React?
React source — packages/react-reconciler/src/ReactFiberHooks.js (mountState, dispatchSetState, mountWorkInProgressHook) and packages/react-reconciler/src/ReactFiberConcurrentUpdates.js (enqueueConcurrentHookUpdate, finishQueueingConcurrentUpdates) in the facebook/react repo.
Lydia Hallie — for JavaScript visualizations that shaped this series' style.

Part 7 is next — performance: what actually causes unnecessary re-renders, before we reach for any optimization tools. 🔧

Tags: #react #javascript #webdev #tutorial

How React Works (Part 5)? The React Lifecycle From the Inside: When Things Actually Run

Sam Abaasi — Sat, 02 May 2026 13:03:02 +0000

The React Lifecycle From the Inside: When Things Actually Run

Series: How React Works Under the Hood
Part 1: Motivation Behind React Fiber: Time Slicing & Suspense
Part 2: Why React Had to Build Its Own Execution Engine
Part 3: How React Finds What Actually Changed
Part 4: The Idea That Makes Suspense Possible
Prerequisites: Read Parts 1–4 first.

A Puzzle Most React Developers Get Wrong

Quick quiz. What order do these log?

function App() {
  useLayoutEffect(() => {
    console.log('layout effect');
  });

  useEffect(() => {
    console.log('effect');
  });

  console.log('render');
  return <div />;
}

Most people guess: render → effect → layout effect, or render → layout effect → effect.

The answer is: render → layout effect → effect.

But more importantly — why? Why does useLayoutEffect run before useEffect? Why does useEffect run at all after the component already returned? What does "after the browser paints" actually mean, and is that even always true?

This article answers all of that. And by the end, you'll be able to look at any component and predict exactly when each piece of it runs — and why.

The Three Phases of a React Render

Before we get into effects, we need to remember the pipeline from Part 2. Every React update goes through three phases:

Render — React runs your component functions, diffs the trees, figures out what changed. Nothing is written to the DOM yet. This is where console.log('render') fires.

Commit — React takes everything it figured out during Render and applies it to the real DOM. This is synchronous and uninterruptible.

Effects — After the DOM is updated, React runs your effects.

The key insight is that effects are not part of rendering. They're a separate step that happens after the DOM is already updated. This is why you can safely read the DOM inside an effect — by the time it runs, the DOM reflects the current state.

What `useEffect` Actually Is

Here's the mental model most developers have: useEffect is "code that runs after render." That's roughly right but missing the important details.

Here's the more accurate model: useEffect is a declaration that you have side effects to run after React is done with the DOM. You're not scheduling a callback — you're telling React about work that needs to happen, and React decides when to run it.

The distinction matters because React doesn't run effects immediately after commit. It schedules them.

From jser.dev's lifecycle article — here's what actually happens:

After the Commit phase finishes updating the DOM, React schedules your useEffect callbacks as a separate task in the Scheduler's queue — the same Scheduler we covered in Part 2. That means effects run in a new macro task, after the browser has had a chance to paint the updated screen.

This is why the React docs say useEffect runs "after the browser paints." The sequence looks like this:

1. Render phase — your component functions run
2. Commit phase — DOM is updated
3. Browser paints the screen
4. Scheduler fires — useEffect callbacks run

The browser gets step 3 because steps 1-2 are one macro task, and step 4 is a new macro task. Between any two macro tasks, the browser can paint.

The Cleanup: Why It Runs Before the Next Effect

Every useEffect can return a cleanup function:

useEffect(() => {
  const subscription = subscribe(id);
  return () => subscription.unsubscribe(); // cleanup
}, [id]);

When id changes and the effect needs to re-run, React runs the cleanup of the previous effect first, then runs the new effect. Always in that order.

This is also true on unmount — the cleanup runs when the component leaves the tree.

The reason is straightforward: React never wants two instances of the same effect active at the same time. Before setting up the new subscription, it tears down the old one. This is React being deliberate about side effects — always clean up before you set up again.

From jser.dev's effect lifecycle article: cleanups run first in commitPassiveUnmountEffects, then new effects run in commitPassiveMountEffects. Both happen in the same scheduled task, in the same order as the tree (children before parents, same as completeWork).

`useLayoutEffect`: The Synchronous Version

Here's the critical difference: useLayoutEffect runs synchronously inside the Commit phase, before the browser paints.

The sequence with useLayoutEffect:

1. Render phase — component functions run
2. Commit phase — DOM is updated
3. useLayoutEffect callbacks run ← here, synchronously, before paint
4. Browser paints
5. useEffect callbacks run ← here, in next macro task

This is why useLayoutEffect fires before useEffect in our opening quiz — it's not "earlier in the same phase," it's in a completely different phase.

And this is why useLayoutEffect exists at all. If you need to read the DOM after it's updated but before the user sees it — for example, measuring an element's size to position a tooltip — useLayoutEffect is the only place where that's safe and accurate.

// useLayoutEffect — correct for DOM measurements
useLayoutEffect(() => {
  const rect = ref.current.getBoundingClientRect();
  setTooltipPosition({ top: rect.bottom, left: rect.left });
});

// useEffect — would cause a visible flicker for measurements
// because the browser already painted before this runs
useEffect(() => {
  const rect = ref.current.getBoundingClientRect();
  setTooltipPosition({ top: rect.bottom, left: rect.left }); // too late
});

If you use useEffect for a DOM measurement that affects layout, the user will briefly see the wrong layout (before useEffect runs), then see it jump to the correct layout (after). That flicker is exactly what useLayoutEffect prevents.

The "After Paint" Rule Has an Exception

Here's something jser.dev discovered that React's own documentation gets wrong.

The docs say useEffect always runs after the browser paints. But that's not strictly true.

Sometimes React runs useEffect callbacks before paint. This happens when React determines it's more important to show the latest UI as quickly as possible — for example, when a re-render is triggered by a user interaction, or when effects are scheduled under layout effects. In those cases, React won't wait for a paint before running the effects.

From jser.dev's paint timing article:

"I'd explain the timing of running useEffect() callbacks as follows. useEffect() callbacks are run after DOM mutation is done. Most of the time, they are run asynchronously after paint, but React might run them synchronously before paint when it is more important to show the latest UI — for example when re-render is caused by user interactions or scheduled under layout effects, or simply if React has the time internally to do so."

The practical implication: never rely on useEffect to run after paint for correctness. If your code requires running after the browser paints, useLayoutEffect with its explicit synchronous-before-paint guarantee is actually the more predictable choice. And if you truly need to run something after paint for non-DOM reasons, the gap is usually small enough not to matter.

The Dependency Array: What It Actually Controls

The dependency array in useEffect and useLayoutEffect doesn't control whether the effect runs — it controls when it re-runs.

React compares the current values of the dependency array to the previous ones using Object.is (similar to === but handles NaN and -0 correctly). If any value changed, React marks the effect with a flag indicating it should run again. If nothing changed, the effect is skipped this cycle.

useEffect(() => {
  fetchUser(id);
}, [id]); // only re-runs when id changes

Three cases:

No dependency array — re-runs after every render. The effect has no conditions.

Empty array [] — runs once on mount, cleanup runs on unmount. Effect has no dependencies that can change.

Array with values — re-runs whenever any listed value changes between renders.

The important thing to understand: React doesn't track what you use inside the effect. It trusts the dependency array you provide. If you use userId inside the effect but forget to put it in the array, React won't re-run the effect when userId changes — and you get a stale value bug. This is why eslint-plugin-react-hooks exists: it statically analyzes your effect and warns when the array is incomplete.

The Full Lifecycle in One Timeline

The pattern is consistent across every scenario. On mount, the component renders, React commits the DOM, useLayoutEffect fires synchronously before the browser paints, the browser paints, then useEffect runs in the next macro task. On update, cleanups always run before new effects — layout cleanup first, then layout create, then paint, then passive cleanup, then passive create. On unmount, both cleanups run in the same order, layout before passive, with paint in between.

Two things are always true regardless of the scenario: layout effects are synchronous and pre-paint, passive effects are scheduled and post-commit. And cleanups always run before the next effect of the same type — React never has two instances of the same effect active at once.

When to Use Which

Use useEffect for everything by default. Most side effects — data fetching, subscriptions, logging, timers — don't need to happen before the browser paints. Running them after paint keeps the UI responsive and is the right choice in the vast majority of cases.

Reach for useLayoutEffect only when you need to read or modify the DOM before the user sees it — measuring element dimensions, positioning a tooltip relative to another element, or preventing a visual flicker. The practical test is simple: if swapping useLayoutEffect for useEffect causes a visible jump or flash in the UI, you needed useLayoutEffect. If it looks identical, stick with useEffect.

What's Coming in Part 6

In Part 6 we go inside useState — how state is stored on the Fiber, what happens when you call setState, and why calling setState multiple times in one event handler doesn't cause multiple re-renders.

🎬 Watch These

JSer (jser.dev) — The lifecycle of effect hooks in React
The source for the Effect object internals, HookHasEffect tag, flushPassiveEffects, and cleanup ordering in this article.

JSer (jser.dev) — How does useLayoutEffect() work internally?
The synchronous commit-phase timing of layout effects vs passive effects — the source for the timing difference explained here.

JSer (jser.dev) — When do useEffect() callbacks get run? Before paint or after paint?
The surprising finding that React.dev's "always after paint" description is inaccurate — and the real timing rules.

🙏 Sources & Thanks

jser.dev — all timing mechanics in this article come from JSer's source-level analysis. Articles used: The lifecycle of effect hooks in React, How does useLayoutEffect() work internally?, How does useEffect() work internally in React?, and When do useEffect() callbacks get run? — including the quote about React.dev's inaccurate description.
React source — ReactFiberCommitWork.js (commitLayoutEffects, commitPassiveMountEffects, commitPassiveUnmountEffects) and ReactFiberWorkLoop.js (scheduleCallback for passive effects).
Lydia Hallie — for JavaScript visualizations that shaped this series' style.

Part 6 is next — how useState actually works: where state lives, what happens when you call setState, and why multiple calls in one handler don't cause multiple re-renders. 🔧

Tags: #react #javascript #webdev #tutorial

How React Works (Part 4)? The Idea That Makes Suspense Possible

Sam Abaasi — Sat, 02 May 2026 12:09:09 +0000

The Idea That Makes Suspense Possible

Series: How React Works Under the Hood
Part 1: Motivation Behind React Fiber: Time Slicing & Suspense
Part 2: Why React Had to Build Its Own Execution Engine
Part 3: How React Finds What Actually Changed
Prerequisites: Read Parts 1–3 first.

A Question Before We Start

Think about how you fetch data in a React component today. You probably do something like this:

function UserProfile({ id }) {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetchUser(id).then(data => {
      setUser(data);
      setLoading(false);
    });
  }, [id]);

  if (loading) return <Spinner />;
  return <div>{user.name}</div>;
}

It works. But look at what you had to do: manage two pieces of state, write an effect, handle the loading condition manually, repeat this pattern in every component that fetches data.

Now look at what Suspense lets you write instead:

function UserProfile({ id }) {
  const user = fetchUser(id); // just... read the data
  return <div>{user.name}</div>;
}

<Suspense fallback={<Spinner />}>
  <UserProfile id={1} />
</Suspense>

No loading state. No effect. No condition. The component just reads data as if it's already there. If it isn't, React handles the waiting — including showing the spinner — automatically.

How is this possible? How can a component just "pause" mid-render and resume when data arrives?

The answer involves a concept called algebraic effects — and understanding it will make Suspense, ErrorBoundary, and some of React's most surprising behaviors finally make sense.

Start With Something You Already Know: `throw`

Algebraic effects sound academic. But Dan Abramov wrote one of the best explanations of them, and he started with something every JavaScript developer already knows: try / catch.

Here's how throw works:

function getName(user) {
  if (user.name === null) {
    throw new Error('no name');
  }
  return user.name;
}

try {
  getName(user);
} catch (err) {
  console.log('handled:', err.message);
}

Notice what throw actually does. It doesn't decide what happens when the error occurs. It just signals that something happened. The catch block somewhere up the call stack is what decides the behavior.

This separation — signaling something vs handling it — is the core idea.

And notice: it doesn't matter how deep getName is in the call stack. It could be called 100 functions deep. throw bypasses all of them and finds the nearest catch. The middle layers don't have to do anything. They don't even know about the error.

The Problem With `try / catch`: No Coming Back

try / catch has one limitation that matters a lot.

When you throw, execution stops at that point. The catch block runs. And that's it — you can never go back to the line that threw and continue from there.

function getName(user) {
  if (user.name === null) {
    throw new Error('no name');
    // ← once you throw, you can NEVER resume here
  }
  return user.name;
}

For errors, this makes sense. But what if you wanted to ask the surrounding context a question and then continue based on the answer?

Like: "I need this user's name. I don't have it. Can someone provide it? I'll wait here."

That's what algebraic effects enable. Dan Abramov described it as a "resumable try / catch."

Algebraic Effects: A Resumable `try / catch`

Algebraic effects don't exist in JavaScript yet. They're a research concept — supported only by a handful of languages built specifically to explore the idea. But Dan Abramov explained them using a hypothetical JavaScript dialect, and his explanation is the clearest one I've found. Let's walk through it.

Imagine JavaScript had two new keywords: perform and resume with.

perform works like throw — it signals something to the surrounding context and finds the nearest handler up the call stack. The crucial difference: it doesn't stop execution. The handler can call resume with to jump back to exactly where perform was called and continue from there, passing a value back in.

Here's Dan's example. We have a function that needs a user's name but doesn't have it:

// Hypothetical JavaScript — this doesn't exist yet
function getName(user) {
  if (user.name === null) {
    // 1. Signal: "I need a name" — but don't stop
    const name = perform 'ask_name';
    // 4. Resume here — name is now 'Arya Stark'
  }
  return user.name;
}

try {
  makeFriends(arya, gendry);
} handle (effect) {
  if (effect === 'ask_name') {
    // 2. Handler catches it — like catch
    // 3. Resume with a value — unlike catch
    resume with 'Arya Stark';
  }
}

The numbered steps show what happens: perform signals (1), the handler catches it (2), the handler provides a value (3), execution jumps back to where perform was and continues with that value (4).

Notice what this doesn't require. makeFriends — the function between getName and the handler — doesn't know anything about this. It didn't have to be modified. It didn't have to pass anything through. The effect just bypassed it entirely, exactly like throw bypasses intermediate functions on its way to catch.

This is what Dan calls "a function has no color." With async/await, making one function async infects every function above it — they all have to become async too. With algebraic effects, a deeply nested function can perform an effect without any of the layers above it caring. The handler somewhere at the top decides what to do, and execution resumes as if nothing unusual happened.

What makes this more powerful than `try / catch`

With regular try / catch, the handler is always synchronous and can never return a value back to the thrower. With algebraic effects, the handler can:

Respond synchronously — resume with an immediate value
Respond asynchronously — call resume with inside a setTimeout or after a fetch
The code that did perform doesn't need to know which one happened

This last point is the key. The same getName function works whether the handler looks up the name from memory, fetches it from a database, or generates it randomly. The function that needs the effect is completely decoupled from how the effect is fulfilled.

That decoupling — signal here, handle somewhere above, resume back here — is the entire concept. And it maps almost exactly onto what React does with Suspense.

Suspense Is React's Implementation of This Idea

JavaScript doesn't actually have perform and resume with. They don't exist. But React simulates this pattern using the tools JavaScript does have: throw and Fiber.

Here's what actually happens when a component suspends:

The component throws a Promise.

When fetchUser(id) is called and the data isn't in the cache yet, instead of returning null or undefined, it throws a Promise — the Promise that will resolve when the data arrives.

// Inside the data fetching library
function fetchUser(id) {
  const cached = cache.get(id);

  if (cached === 'pending') {
    throw promise; // ← this is the "perform"
  }
  if (cached === 'resolved') {
    return cache.get(id); // ← data is ready, return normally
  }

  // Start the fetch, mark as pending, throw
  const promise = fetch(`/users/${id}`).then(data => cache.set(id, data));
  cache.set(id, 'pending');
  throw promise;
}

React catches the thrown Promise.

Because React's render loop runs inside a try / catch, it catches the thrown Promise. This is the "handler" in the algebraic effects model — React itself acts as the effect handler.

React shows the fallback.

React walks up the Fiber tree to find the nearest <Suspense> boundary and shows its fallback — the <Spinner /> — while waiting.

When the Promise resolves, React retries.

When the data arrives, React re-renders the component from the <Suspense> boundary downward. This time, the cache has the data. fetchUser returns normally instead of throwing. The component renders successfully.

As Sam Galson described it:

"A component is able to suspend the fiber it is running in by throwing a promise, which is caught and handled by the framework. When the promise resolves, its value is added to a cache, the fiber is restarted, and the next time the data is requested it is accessed synchronously from cache."

Why This Only Works Because of Fiber

Here's the critical question: when a component throws mid-render, wouldn't all the work React did to reach that point be lost?

With the old synchronous call stack — yes. Throwing would unwind the entire stack, destroying every local variable and stack frame on the way up.

But React uses Fiber, not the native call stack, to track rendering work. Fibers are plain JavaScript objects — they survive the throw. They sit in memory exactly as they were.

When React catches the thrown Promise and shows the fallback, all the Fiber work up to that point is preserved. When the data arrives and React retries, it resumes from the Suspense boundary without re-doing all the ancestor work.

This is what Sam Galson meant when he wrote that the throw-based approach "isn't problematic for React because it relies on fibers not the native call stack to track program execution."

Fiber made algebraic-effect-style control flow possible in JavaScript. Without Fiber, throwing a Promise would be catastrophic. With Fiber, it's just a pause.

ErrorBoundary Is the Same Pattern

Once you understand Suspense through this lens, ErrorBoundary becomes obvious — it's the same mechanism, just for actual errors instead of Promises.

When a component throws an error during rendering, React walks up the Fiber tree looking for the nearest class component that implements getDerivedStateFromError. When it finds one, it re-renders that component with error state, showing the fallback UI instead of the crashed subtree.

The component that threw didn't decide what happens — it just threw. The ErrorBoundary somewhere up the tree decided the behavior. Sound familiar?

That's the same separation as perform and handle. The throwing component signals something happened. The handler decides what to do.

class ErrorBoundary extends React.Component {
  static getDerivedStateFromError(error) {
    return { hasError: true }; // ← this is the "handle"
  }

  render() {
    if (this.state.hasError) {
      return <h1>Something went wrong.</h1>;
    }
    return this.props.children;
  }
}

The key difference from Suspense: ErrorBoundary doesn't resume. Once a component threw an error, that render is abandoned. The boundary re-renders with fallback. Suspense, by contrast, genuinely retries the original render when the data arrives.

The Bigger Picture

Dan Abramov wrote in his algebraic effects article that the React team — specifically Sebastian Markbåge — had been using algebraic effects as a mental model for years:

"My colleague Sebastian kept referring to them as a mental model for some things we do inside of React. At some point, it became a running joke on the React team."

Hooks follow the same idea too. When you call useState inside a component, that component doesn't know or care where its state is actually stored. It just performs a "request for state" and React — the handler — provides it from the Fiber's hook linked list. The component doesn't reach into React's internals. React provides the value through the call.

This separation — components declaring what they need, React deciding how to provide it — is algebraic effects thinking applied to a UI library. And it's why React's API feels declarative even when the underlying behavior is complex.

What's Coming in Part 5

In Part 5 we look at the React lifecycle from the inside — initial mount, re-render, useEffect, and useLayoutEffect. We'll trace exactly when each fires, why the order is what it is, and what "after the browser paints" actually means.

🎬 Watch These

Sam Galson — Magic in the web of it: coroutines, continuations, fibers | React Advanced London
The CS foundation — fibers, coroutines, and how React uses the throw/catch mechanism to simulate algebraic effects. The source for the Fiber + algebraic effects connection in this article.

Matheus Albuquerque — Inside Fiber | React Summit 2022
Start at 12:46 — Matheus shows how Context API was designed using algebraic effects thinking, and how Suspense connects to it.

🙏 Sources & Thanks

Dan Abramov — Algebraic Effects for the Rest of Us on overreacted.io. The full three-step build in this article — try/catch → limitation → perform/resume with — follows Dan's progression directly. The Arya Stark example, the "resumable try/catch" framing, the "function has no color" insight about async infection, the async handler example, and the quote about Sebastian Markbåge using algebraic effects as a running joke on the React team — all come verbatim or paraphrased from this article. Read it after this one.
Sam Galson — Magic in the web of it (talk) and Continuations, coroutines, fibers, effects (article). The quote about how "a component is able to suspend the fiber it is running in by throwing a promise" and the throw-handle-resume pattern description come directly from Sam's article.
Sebastian Markbåge — for the original "Poor man's algebraic effects" gist that modeled the technique later used by React Suspense, cited in Sam Galson's article.
jser.dev — source verification of how throwException, the Suspense retry mechanism, and ErrorBoundary recovery actually work in the React codebase.

Part 5 is next — the React lifecycle from the inside: when useEffect and useLayoutEffect fire, and why the order is exactly what it is. 🔧

Tags: #react #javascript #webdev #tutorial

How React Works (Part 3)? How React Finds What Actually Changed

Sam Abaasi — Sat, 02 May 2026 11:32:44 +0000

How React Finds What Actually Changed

Series: How React Works Under the Hood
Part 1: Motivation Behind React Fiber: Time Slicing & Suspense
Part 2: Why React Had to Build Its Own Execution Engine
Prerequisites: Read Parts 1 and 2 first.

Where We Left Off

In Part 2 we understood the engine — Fiber gives React a custom call stack it controls, and the Scheduler decides what to run and when.

Now the question is: what does React actually do with that engine?

Every time state changes, React has a problem. It knows the old version of your UI and the new version. But it's working with a tree of potentially thousands of components. Re-creating or re-rendering all of them on every update would be catastrophically slow.

React needs to answer one question as efficiently as possible:

"Of everything that could have changed, what actually did?"

The algorithm that answers that question is called the Reconciler.

The Problem: Re-rendering Everything Is Too Slow

Let's make the problem concrete. You have an app with 500 components. A user clicks a button that changes one counter inside one component. Naively, React would need to re-run every component function, create new JSX, and compare it to the old DOM — 500 times — to figure out that exactly one <span> needs its text updated.

That's what old-school frameworks did. It's why they felt slow.

React's insight was: most of the tree didn't change. If React can quickly identify which parts of the tree could possibly have changed, it can skip everything else and only do real work on the parts that matter.

The Reconciler is that skip logic.

The First Skip: Following the Trail

When you call setState inside a component, React doesn't just mark that one component for update. It marks a trail — like breadcrumbs from that component all the way back to the root of the tree.

Every ancestor gets a small flag saying: "one of your descendants has work to do."

Then when React walks the tree to find what needs re-rendering, it uses those flags like a GPS. At every node it asks: "Does this node have work? No? Do any of its children have work? Also no?" If both answers are no, React skips that entire subtree in one step — not just the node, but every component inside it.

This is how a click inside one deeply nested component avoids touching the 490 components that had nothing to do with it. React walks straight down the trail of flags, skips every branch that's clean, and only stops at the one component that actually changed.

The Second Skip: Props Haven't Changed

React made it to the component that has work. But before actually re-running it, React checks one more thing: did this component's inputs (props) change?

If a parent re-renders, it might generate new props for its children. But "new" doesn't always mean "different." React compares the old props to the new props. If they're the same object reference — same pointer in memory — React skips re-rendering that component entirely.

This is reference equality, not deep equality. React doesn't compare every field inside the props object. It just checks: is this the exact same object we had before?

If yes — skip. The component can't possibly look different, so there's nothing to do.

This is also exactly how React.memo works. React.memo wraps a component and adds one step: when React would normally re-render because the props reference changed, React.memo does a shallow comparison of each prop value. If they all match, it skips. If even one is different, it re-renders normally.

And this is why passing a new object as a prop breaks memoization:

// This breaks React.memo — new object created every render
<Button style={{ color: 'red' }} />

// This works — same reference if color hasn't changed
const style = useMemo(() => ({ color: 'red' }), []);
<Button style={style} />

The {} on the first line creates a brand-new object every single render. Even though its contents are identical, it's a different object in memory. React sees "different reference" and re-renders.

When React Does Need to Re-render: Type vs Content

React made it to a component that needs updating. It runs the component function, gets new JSX back, and now needs to figure out what changed by comparing old output to new output.

The first thing React checks is the type of each element. Not the content — the type.

If you had a <div> and now you have a <span>, React doesn't try to figure out how to transform one into the other. It destroys the <div> completely — the DOM node, the fiber, all state inside it — and creates a fresh <span> from scratch.

This is a hard rule: same type means update in place, different type means destroy and recreate.

This rule has a real consequence that surprises developers:

// Every time isLoggedIn changes, the entire form loses its state
{isLoggedIn ? <UserForm /> : <GuestForm />}

// UserForm and GuestForm are different types — React destroys one and creates the other
// Any input values typed into the form are gone

If you want to keep state when switching between two components, they need to be the same type, rendered at the same position in the tree. Different types always means starting over.

The List Problem: Why `key` Exists

Single elements are straightforward to diff. Lists are where it gets genuinely hard.

Imagine you have a list of 5 items. Now you add a new item at the top. From React's perspective, looking position by position: position 1 changed, position 2 changed, position 3 changed, position 4 changed, position 5 changed, position 6 is new. It looks like every single item changed — even though you just prepended one.

Without any extra information, React would re-render all 5 existing items unnecessarily.

This is what key solves. A key is a stable identifier that tells React: "this item is this item, regardless of where it appears in the list."

With keys, React builds a lookup table of all existing items keyed by their identifier. Then for each new item in the list, it looks up: "do I already have a fiber for this key?" If yes, reuse it. If no, create it fresh. Items that were in the old list but aren't in the new one get deleted.

The practical result: prepend one item to a list of 1000, and React creates exactly one new fiber. The other 999 are reused instantly.

Why index as key breaks things:

// Dangerous — index as key
items.map((item, i) => <Row key={i} data={item} />)

When you prepend a new item, every index shifts. The new item gets key=0, which used to belong to the old first item. React thinks it's reusing the old component — but it's actually showing different data through the same fiber. State from the old item leaks into the new item. Form inputs show wrong values. This is a genuinely hard bug to track down.

The fix is always the same: use something stable and unique as the key — an ID from your data, a slug, anything that doesn't change when the list is reordered.

After Finding the Changes: Marking, Not Doing

Here's a subtle but important detail about how React works.

During the Reconciler's walk of the tree, React does not touch the real DOM. It doesn't insert nodes, update text, or remove elements. It only marks fibers with notes about what needs to happen:

This fiber needs a new DOM node inserted
This fiber's props changed and the DOM needs updating
This fiber was removed and its DOM node should be deleted

Think of it like a doctor marking a patient's chart before surgery — deciding what needs to happen, not doing it yet.

Only after the entire tree has been walked and all decisions are made does React move to the Commit phase — where it reads those marks and makes the actual DOM changes, all at once, in a single synchronous pass.

This separation is what makes React's updates feel atomic. You never see a half-updated UI. Either the whole update is done, or none of it is.

The Full Picture in One Paragraph

Every state change triggers a tree walk. React follows a trail of flags to find what might have changed, skips every clean subtree instantly, checks whether props actually changed before re-running anything, compares old and new output by type first and content second, uses key props to track list items regardless of position, and marks everything that needs updating — without touching the DOM. Then, in one final pass, it applies all the marks at once.

That's reconciliation. It's why updating one input in a form with 200 fields is fast, why React.memo works, and why key is not optional for lists.

What's Coming in Part 4

In Part 4 we look at one of the most interesting ideas React borrowed from academic computer science to make Suspense and ErrorBoundary work — algebraic effects. It's simpler than it sounds, and understanding it will make how Suspense actually works finally click.

🎬 Watch These

JSer (jser.dev) — How does React re-render internally?
Source-level walkthrough of the re-render process — the trail of flags, props comparison, and the two-phase render/commit split.

JSer (jser.dev) — How does React bailout work?
Why most of your component tree gets skipped on every render, and what exactly triggers a re-render vs a skip.

JSer (jser.dev) — How does 'key' work internally?
The full list diffing algorithm — how React uses keys to match old and new items, and why the wrong key causes bugs.

🙏 Sources & Thanks

jser.dev — the bailout mechanics (trail of flags, props comparison), re-render algorithm, and key/list diffing all come from JSer's source-level analysis. Articles: How does React re-render internally?, How does React bailout work?, How does 'key' work internally?
Andrew Clark — react-fiber-architecture — the reconciler/renderer separation that explains why React marks before it commits.
Lydia Hallie — for JavaScript visualizations that shaped this series' style.

Part 4 is next — algebraic effects, and how Suspense actually works under the hood. 🔧

Tags: #react #javascript #webdev #tutorial

How React Works (Part 2)? Why React Had to Build Its Own Execution Engine

Sam Abaasi — Sat, 02 May 2026 10:44:11 +0000

Why React Had to Build Its Own Execution Engine

Series: How React Works Under the Hood
Part 1: Motivation Behind React Fiber: Time Slicing & Suspense
Prerequisites: Read Part 1 first — this article picks up exactly where it left off.

Where We Left Off

In Part 1 we landed on one sentence that explains why React had to be completely rewritten:

React needs to be able to interrupt what it's doing and resume it later.

Time Slicing needs it — to yield within the browser's 16ms frame budget.
Suspense needs it — to pause and wait for async data.

Simple enough requirement. But here's the problem: JavaScript itself won't let you do it.

This article is about why that's true, what React did about it, and why that decision — building an entirely custom execution model — is what makes modern React possible.

The Problem: JavaScript Runs to Completion

When JavaScript starts executing a function, it finishes it. There is no external API to say "pause here, do something else, come back." There is no way to freeze a running program mid-execution, hand control back to the browser, and resume from the exact same spot.

This is because JavaScript manages execution with something called the call stack — a data structure that tracks what the program is doing at any moment.

Every time a function is called, JavaScript creates a stack frame — a small record of that function's parameters, local variables, and where to return to when it finishes. These frames stack up as functions call other functions, and pop off as they return.

Here's the critical property of this stack: it's managed entirely by the JavaScript engine. You — the developer — cannot read it, pause it, or jump around in it. It's a black box. Once a chain of function calls starts, it runs to completion. The browser can't paint. The user can't interact. Nothing happens until the stack is empty.

For old React, this was fine. React rendered your whole tree in one big chain of function calls. The browser waited. Nobody noticed because apps were small enough.

But for Time Slicing — where React needs to stop mid-render, let the browser paint, then resume — this model is a hard wall. You can see the exact moment React solved it in two lines from the React source:

// Old — no way out until every component is done
function workLoopSync() {
  while (workInProgress !== null) {
    performUnitOfWork(workInProgress);
  }
}

// New — checks after every single component
function workLoopConcurrent() {
  while (workInProgress !== null && !shouldYield()) {
    performUnitOfWork(workInProgress);
  }
}

One extra condition: !shouldYield(). That's it. After every component, React asks: "Is the browser waiting? Is there higher-priority work?" If yes, the loop breaks. But for this to be safe — for breaking mid-loop to not lose work — React needed somewhere to store what it was doing. That storage is Fiber.

Sam Galson described it precisely in his talk "Magic in the web of it":

"Unlike stack frames, fibers can also keep around local data like state even if they're not currently active. With a stack frame, when it's popped off the stack, all of the local information stored in it is gone. But that's not the case with a fiber."

The Insight: What If React Had Its Own Stack?

Here's the idea that changed everything.

The native JavaScript call stack is a constraint because React doesn't control it. But what if React built its own version — one that it does control?

Not a replacement for JavaScript's stack. JavaScript still runs normally. But React would track its own rendering work in a data structure it manages itself. One it can pause, inspect, prioritize, and resume at any moment.

This is what React Fiber is. It is React's own custom execution model, built in plain JavaScript objects, sitting on top of JavaScript's normal execution.

Sam Galson described the CS concept behind it:

"A fiber is just a generic way to model program execution in a way where each individual unit of work works together cooperatively. No single fiber attempts to dominate the program."

React didn't invent this idea. Fibers exist in operating systems. Microsoft Windows uses them. OCaml built its entire concurrency model on them. The concept is old — React just brought it to the browser.

What a Fiber Actually Is

In JavaScript's call stack, a stack frame holds:

What function is running
What parameters it was called with
What local variables it has
Where to return to when done

A Fiber holds the exact same information — but for a React component:

Stack frame	Fiber equivalent
The function	Your component (`App`, `Button`, etc.)
Parameters	Props being passed in
Local variables	State and hooks
Return address	The parent component

The difference that makes everything possible: stack frames live inside the JavaScript engine where you can't touch them. Fibers are just plain JavaScript objects. React creates them, reads them, pauses on them, and resumes them — completely under its own control.

Here's what a fiber for a <Button> component actually looks like at runtime:

{
  type: Button,              // your component function
  pendingProps: { label: "click me" },  // props coming in
  memoizedState: { count: 0 },          // state lives here
  return: ParentFiber,       // parent — like a return address
  child: null,               // first child component
  sibling: null,             // next sibling component
  alternate: null,           // the other version of this fiber
}

That's it. A regular JavaScript object. Nothing magical. The fact that it's just an object is what makes pausing safe — React can stop at any point, and the fiber is still sitting in memory exactly as it was.

And because fibers are objects, they can hold more than stack frames can. Each fiber knows not just its parent (like a return address) but also its first child and its next sibling. This means React can navigate the entire component tree from any point — forward, backward, sideways — without losing track of where it is.

When the browser needs to paint, React stops updating workInProgress (its pointer to the current fiber), yields control, and returns to the work loop later. The fiber is still sitting in memory, exactly as React left it. Nothing was lost.

Two Trees, Always

Here's one more piece of the picture that makes this safe.

React always keeps two versions of your component tree in memory at the same time:

The current tree — what's actually showing on screen right now
The work-in-progress tree — what React is building for the next render

All rendering work happens on the work-in-progress tree. The current tree is never touched during rendering. So if React gets interrupted mid-render, the screen doesn't flicker or break — the current tree is still intact and showing correctly.

When the new tree is fully built and ready, React swaps them in one atomic operation. What was work-in-progress becomes current. What was current becomes the next work-in-progress (ready to be reused for the render after that).

This pattern — keeping two versions and building the new one safely before switching — is called double buffering. It's the same technique video games use to prevent screen tearing. React borrowed it for exactly the same reason: you never want to show the user a half-built state.

How the Scheduler Uses This

Now the Scheduler — the module that decides when and in what order work runs — can do things that were completely impossible before.

Pause and resume. When shouldYield() returns true (time budget used up), the work loop simply stops. The workInProgress pointer stays exactly where it is. Next time the Scheduler gets control, the loop continues from that fiber. No work is lost. No state is rebuilt.

Prioritize. Because fibers are objects React controls, it can look at any fiber's priority (lanes) and decide to work on a different part of the tree first. A keystroke comes in while React is rendering a heavy chart? React stops the chart render, handles the keystroke (which runs at higher priority), then comes back to the chart from exactly where it left off.

Abort. If a newer update makes the current work-in-progress tree obsolete, React can throw it away entirely and start fresh with updated data. The current tree on screen is unaffected.

None of these were possible when rendering was one continuous chain of JavaScript function calls.

The Full Picture in One Paragraph

React saw that JavaScript's call stack — fast, simple, but completely opaque — was incompatible with the kind of interruptible, prioritized rendering that modern apps need. So it built a replacement: a tree of plain JavaScript objects (fibers) where each object is a stack frame React controls. It keeps two copies of this tree so it can always build the next version safely without disturbing what's on screen. And it has a Scheduler that decides what to work on next, how long to work before yielding, and how to resume exactly where it stopped.

That system — Fiber + Scheduler — is the engine underneath every useState, every useTransition, every <Suspense> boundary, every animation that doesn't drop frames.

What's Coming in Part 3

Now that we understand the engine, we can look at what the engine actually does — how React figures out which parts of your UI actually changed, and how it updates the minimum number of DOM nodes to reflect that. That's the Reconciler, and it's where key props, React.memo, and most of your performance intuitions come from.

🎬 Watch These

Sam Galson — Magic in the web of it: coroutines, continuations, fibers | React Advanced London
The computer science behind why Fiber works — what fibers are in CS terms, how they differ from threads and coroutines, and why React chose this model. The source for the cooperative execution framing in this article.

Dan Abramov — Beyond React 16 | JSConf Iceland 2018
The original demo of the problem this article solves. Watch 2:57 to feel exactly why the call stack was a problem.

Matheus Albuquerque — Inside Fiber | React Summit 2022
Goes deeper on the FiberNode data structure if you want the implementation detail. Start at 2:11.

🙏 Sources & Thanks

Sam Galson — Magic in the web of it (talk) and Continuations, coroutines, fibers, effects (article). The cooperative execution framing, the "fibers existed before React" point, and the comparison between fibers and stack frames all come from Sam's work.
Andrew Clark — react-fiber-architecture. The definition of Fiber as "a reimplementation of the stack, specialized for React components" and the double buffering concept.
jser.dev — source-level verification of how the two-tree system, workInProgress, and the Scheduler work loop actually behave in the React codebase.

Part 3 is next — the Reconciler: how React finds the minimum set of changes needed to update your UI, and why key props matter more than you think. 🔧

Tags: #react #javascript #webdev #tutorial

How React Works (Part 1)?Motivation Behind React Fiber: Time Slicing & Suspense

Sam Abaasi — Sat, 02 May 2026 09:58:18 +0000

Motivation Behind React Fiber: Time Slicing & Suspense

Series: How React Works Under the Hood
Level: Intermediate to Advanced
Prerequisites: Basic React knowledge. Bonus: if you've read How JavaScript Works — you'll feel right at home.

Introduction

You've used React. You've felt that lag — the input that stutters, the page that freezes for half a second, the animation that just doesn't feel right. But have you ever wondered why React had to completely rewrite its entire internal engine just to fix it?

In 2017, the React team announced React Fiber — a ground-up rewrite of React's internals. Not the API. Your JSX and components stayed the same. But the engine underneath, the thing that actually decides how and when work gets done, was thrown out and rebuilt from scratch.

To understand why Fiber was necessary — not just useful, but necessary — we need to start where the React team started. This entire article is grounded in Dan Abramov's talk at JSConf Iceland 2018. If you want to watch it alongside reading, here it is:

🎬 Dan Abramov — Beyond React 16 | JSConf Iceland 2018

Now let's get into it.

⚡ The Core Question

"With vast differences in computing power and network speed, how do we deliver the best user experience for everyone?"

This isn't a warm-up. It's the exact design challenge the React team was solving. Think about who uses your app:

A developer on a MacBook Pro with fiber internet
A user in rural Southeast Asia on a 3-year-old Android phone with a 3G connection
Someone on a mid-range laptop on a crowded café WiFi

React runs on all of these. And in 2017, it was doing a poor job of adapting to any of them. The problems fell into two distinct categories.

🖥️ CPU Problems — The Cost of Rendering

These are problems caused by expensive computation. When React updates your UI, it has to do real work: creating DOM nodes, calling render functions, reconciling old and new trees, applying changes to the DOM. On a powerful machine, this might take 5ms. On a low-powered mobile device, the exact same work might take 50ms or more.

CPU problems look like:

A complex chart re-rendering while you're typing
Mounting a large component tree on initial load
Re-rendering a long list when one item changes

🌐 IO Problems — The Cost of Waiting

These are problems caused by time spent waiting for things to arrive — data from an API, a JavaScript bundle from a CDN, an image. The code is fine. The device is fine. You're just waiting on the network.

IO problems look like:

Data-fetching waterfalls — fetch A, then B, then C, each blocking the next
Code splitting — loading a bundle before a page can render
Showing wrong loading states because data arrived faster or slower than expected

Both needed new solutions. And as we'll see, both solutions required the exact same capability from React's engine. But first — let's see the problem in action.

🎬 The Demo That Changed Everything

The best way to feel this problem is to see it. Jump to 2:57 in Dan's talk — this is the moment the demo lands.

The app: an input field at the top, a detailed chart below. The rule: the more characters you type, the more detailed the chart gets. Both updates — the input and the chart — happen at the same time.

Watch the input. There's a clear delay between pressing a key and seeing the character appear. The browser is so busy computing the chart that it can't process keystrokes fast enough. The thread is blocked for the entire duration of the render — which might be 50, 80, even 100ms — and the user feels every millisecond of it.

Dan put the root problem precisely:

"The underlying problem is that the update is big and synchronous — once React starts rendering, it cannot stop."

This is visible directly in the React source code. In synchronous mode, the work loop looks like this:

// From React source — synchronous mode
function workLoopSync() {
  while (workInProgress !== null) {
    performUnitOfWork(workInProgress);
  }
}

It's a plain while loop with no exit condition other than finishing everything. Once React starts, it runs to completion. There is no way to pause it from the outside.

🩹 The Attempted Fix: Debouncing

The most natural workaround: instead of updating the chart on every keystroke, wait until the user pauses typing, then do one big update.

Better? A little. But it has three real problems.

1. It's not adaptive to the device. Debouncing uses a fixed delay — say 300ms. If the user's machine is powerful enough to render instantly, they still wait 300ms. If it's slow, 300ms might not even be enough time for the render to finish without freezing.

2. It still locks up when it fires. Try enabling CPU throttling in DevTools (4–6x slowdown, simulating a low-end phone). Even with debouncing, the moment the update fires, the browser locks up completely. You've moved the jank — not eliminated it.

3. It doesn't help with mounting. Debouncing can delay an update, but when you first mount a large component tree, there's nothing to debounce. React mounts it all at once, synchronously. During that time, nothing in the page is interactive — click events don't register, animations freeze.

The problem isn't when the update fires. It's that the update is synchronous and uninterruptible when it does.

💡 What If React Could Pause?

What if React could start rendering the chart update, notice that a keystroke arrived, pause the render, handle the keystroke immediately, then resume from exactly where it stopped?

The total amount of work is identical. But the experience is completely different — because users get immediate feedback on their input while the expensive work finishes quietly in the background.

To understand why this requires a completely new engine, we need to talk about frames.

🎞️ The 16ms Frame Budget

Browsers aim to run at 60 frames per second. The math:

1000ms ÷ 60 frames ≈ 16.67ms per frame

Every ~16ms, the browser needs to execute JavaScript, recalculate styles, lay out the page, and paint pixels to the screen. If JavaScript takes more than ~16ms in a continuous burst, the browser misses that frame. You see jank — stuttering, freezing, lag.

Old React had no awareness of this budget at all. A single render could take 100ms and React would march through it, never yielding control, never letting the browser breathe.

⏱️ Time Slicing

Time Slicing is React's solution to the CPU problem.

The core idea: instead of doing all rendering in one continuous chunk, React slices that work into small pieces and checks between each piece whether something more urgent has arrived. This is exactly what the concurrent version of the work loop does differently:

// From React source — concurrent mode
function workLoopConcurrent() {
  while (workInProgress !== null && !shouldYield()) {
    performUnitOfWork(workInProgress);
  }
}

Spot the difference from workLoopSync: !shouldYield(). After every single unit of work, React asks the Scheduler: "Is it time to yield?"

Here's the actual shouldYield logic from the React Scheduler source:

function shouldYieldToHost() {
  const timeElapsed = getCurrentTime() - startTime;
  if (timeElapsed < frameInterval) {
    return false; // still have budget — keep working
  }
  return true; // time's up — yield to the browser
}

Each task is given about 5ms. When that time is up, React pauses. The browser gets a chance to handle user input and paint. Then React resumes from exactly where it left off.

The result:

The input updates immediately on every keystroke. The chart still renders — it just does so across multiple frames instead of one big block. The total work is the same. The experience is night and day.

Dan described the properties precisely at JSConf Iceland:

"We've built a generic way to ensure that high-priority updates don't get blocked by a low-priority update, called time slicing. If my device is fast enough, it feels almost like it's synchronous; if my device is slow, the app still feels responsive. It adapts to the device thanks to the requestIdleCallback API. Notice that only the final state was displayed — the rendered screen is always consistent and we don't see visual artifacts of slow rendering causing a janky user experience."

Three properties to lock in:

Feels synchronous on fast devices — slices are so small and fast you never notice them
Feels responsive on slow devices — high-priority work (keystrokes) always gets through
Only the final state is shown — no intermediate render states flash on screen

🌿 The Git Metaphor

Dan used a metaphor in his talk that makes prioritization intuitive.

Without time slicing, React is like working directly on main. An urgent bug comes in mid-feature — you can't fix it. You have to finish the feature first.

With time slicing, React works like a proper branching workflow. You start on a feature branch — the low-priority chart render. An urgent task arrives — a keystroke. You handle it on main first, then rebase your feature branch on top when you're done.

React does the rebasing automatically. The low-priority render continues from where it stopped, now applied on top of the most current state. You never think about it.

⏳ Suspense

If Time Slicing solves the CPU side, Suspense solves the IO side.

Dan introduced it this way:

"We've built a generic way for components to suspend rendering while they load async data, which we call suspense. You can pause any state update until the data is ready, and you can add async loading to any component deep in the tree without plumbing all the props and state through your app and hoisting the logic."

The concept: instead of manually managing loading states with isLoading flags and scattered useEffect fetches, a component can declare that it's waiting and React handles the rest.

function MovieDetails({ id }) {
  // If data isn't cached yet, this suspends — throws a Promise
  const movie = movieCache.read(id);
  return <div>{movie.title}</div>;
}

<Suspense fallback={<Spinner />}>
  <MovieDetails id={42} />
</Suspense>

Internally, when a component suspends, it throws a Promise. React catches it at the nearest <Suspense> boundary, shows the fallback, and retries the render when the Promise resolves. We'll go deep on the exact mechanics — including how this connects to algebraic effects — in Part 4.

What's powerful is how it adapts to network conditions:

"On a fast network, updates appear very fluid and instantaneous without a jarring cascade of spinners that appear and disappear. On a slow network, you can intentionally design which loading states the user should see and how granular or coarse they should be, instead of showing spinners based on how the code is written. The app stays responsive throughout."

And the key point Dan closed with:

"Importantly, this is still the React you know. This is still the declarative component paradigm that you probably like about React."

The mental model for you as a developer doesn't change. The engine underneath does.

🔗 The Common Thread: Interrupting

Here's what ties both features together.

Time Slicing and Suspense look completely different — one is about CPU, one is about IO. But they share one fundamental requirement:

React needs to be able to interrupt what it's doing and resume it later.

Time Slicing: interrupt to yield within the 16ms frame budget
Suspense: interrupt to wait for async data

Same capability. This is exactly why React needed Fiber.

The old React engine used JavaScript's native call stack to track all rendering work. And the native call stack has a hard limitation: you cannot pause it from the outside. Once a stack of function calls starts executing, it runs to completion. There is no JavaScript API to say "stop here, do something else, resume from this exact frame."

Matheus Albuquerque explained the solution beautifully in his React Summit 2022 talk:

"We can think of the Fiber architecture as a React-specific call stack model that gives full control over scheduling of what should be done. And a Fiber itself is basically a stack frame for a given React component."

And crucially — unlike native stack frames, Fibers are just plain JavaScript objects. React can create them, inspect them, pause them, delete them, and resume them whenever it wants. Sam Galson put the key insight in one sentence:

"Fiber is a reimplementation of the stack, specialized for React components. The advantage of reimplementing the stack is that you can keep stack frames in memory and execute them however — and whenever — you want."

This gives us React's internal pipeline, as described by jser.dev:

Trigger — something changes (setState, event). React registers the work.
Schedule — the Scheduler, a priority queue, decides when and in what order work happens.
Render — React walks the Fiber tree and figures out what changed. This phase is interruptible. This is where Time Slicing and Suspense live.
Commit — React applies changes to the real DOM. Synchronous. Cannot be interrupted.

Fiber makes the Render phase interruptible. Everything else follows from that.

🗺️ What's Coming in This Series

This was the why. The rest of the series is the how — each part built around one problem and one solution.

Part	Title	Core story
Part 2	Why React Had to Build Its Own Execution Engine	JS call stack can't pause → React builds Fiber + Scheduler
Part 3	How React Finds What Actually Changed	Re-rendering everything is too slow → the Reconciler + keys
Part 4	The Idea That Makes Suspense Possible	Algebraic effects → how Suspense and ErrorBoundary actually work
Part 5	The React Lifecycle From the Inside	When `useEffect` and `useLayoutEffect` fire and why
Part 6	How State Actually Works	`useState`, `useRef`, dispatch, and the commit state phase
Part 7	The Trap of Vibe Coding `useCallback`	What causes re-renders — before reaching for `memo` and `useCallback`
Part 8	Server Components & Hydration: The Real Story	How React moved rendering to the server — and what it cost
Part 9	The Complete Picture: From a Keystroke to a Pixel	Every layer of React working together as one system

🎬 Watch These Talks

This article is a distillation. The primary sources are worth your time — here's what to watch and why:

Dan Abramov — Beyond React 16 | JSConf Iceland 2018 (33 min)
The talk this entire article is based on. Key moments: the demo at 2:57, the async version revealed at 6:10, the Git metaphor at 8:16, and the Suspense demo from 15:40.

Matheus Albuquerque — Inside Fiber: the In-Depth Overview | React Summit 2022 (27 min)
The deepest walkthrough of FiberNode internals I've found. Start at 2:11 for the Fiber-as-call-stack explanation that directly connects to Part 2 of this series.

Sam Galson — Magic in the web: coroutines, continuations, fibers | React Advanced London (~30 min)
The computer science behind React's approach — coroutines, continuations, algebraic effects, and why Fiber is the shape it is. Essential background for Parts 2 and 3.

🙏 Sources & Thanks

A huge thank you to everyone whose work made this article possible:

Dan Abramov — for Beyond React 16 and for the Git metaphor that makes Time Slicing click
Matheus Albuquerque — for the clearest explanation of FiberNode internals at React Summit 2022. Transcript via gitnation.com
Sam Galson — for connecting React to the wider CS theory of fibers, coroutines, and continuations. Full article: Continuations, coroutines, fibers, effects (YLD Blog)
Sophie Alpert & the React team — Sneak Peek: Beyond React 16 (React Blog) — the official writeup with Dan's exact quotes
jser.dev — the best source-level analysis of React internals on the internet. The workLoopSync, workLoopConcurrent, shouldYieldToHost, and the 4-phase model in this article all come from JSer's series — especially the overview, the scheduler breakdown, and the Lanes deep dive
Lydia Hallie — for in-row and non-in-row fetching explanations and for the JavaScript visualizations that shaped this series' style

Part 2 is next — JavaScript's call stack is why React couldn't do any of this. Here's what React built instead. 🔧

Tags: #react #javascript #webdev #tutorial

The Full Architecture: How a Form-JS Extension System Fits Together

Sam Abaasi — Wed, 29 Apr 2026 06:56:00 +0000

Part 23 of the series: "Extending bpmn-io Form-JS Beyond Its Limits"

This is the last article in the series. It's also the one to read first.

If you've arrived here without reading the others, this article will show you the complete architecture so you can identify which pieces you need and navigate directly to the relevant articles. If you've read all twenty-two articles before this one, this article assembles them into a coherent whole — showing how every piece connects to every other piece and where the system's decisions were made deliberately versus where they were made under pressure and later regretted.

What Was Built

Over twenty-two articles, the system grew to this:

5 evaluators — classes that run on every changed event and maintain runtime state:

BindingEvaluator — computes derived field values from FEEL expressions
HideEvaluator — toggles field visibility based on FEEL conditions
DisabledEvaluator — applies disabled state from expressions or static flags
RequiredEvaluator — enforces dynamic required fields and mutates the schema
PersistentEvaluator — marks fields for application-layer persistence
DateTimeValidationEvaluator — validates datetime fields with scoped re-evaluation
TicketAutoFillEvaluator — async field population from external APIs with caching

12 properties panel providers — classes that extend the form editor's configuration UI:

DisabledPropertiesProvider, ReadonlyPropertiesProvider, RequiredPropertiesProvider — override built-in properties with FEEL-capable versions
FeelExpressionPropertiesProvider — adds FEEL binding entry to Form Logics
HideIfPropertiesProvider — adds hide-if condition entry to Form Logics
PersistentPropertiesProvider — adds persistent flag entry to Form Logics
ShowLatestValuePropertiesProvider — adds show-latest-value entry to Form Logics
TicketAutoFillPropertiesProvider — adds cascading API-backed configuration UI
DropdownPropertiesProvider — replaces simple dropdown with full configuration panel
GridFieldPropertiesProvider — adds grid-specific validation rule configuration
DateTimePropertiesPanelExtension — configures datetime replacement field
FileUploadPropertiesProvider — adds file validation configuration

3 custom validators — classes that extend form.validate():

FeelValidator — FEEL expression-based field validation at submit time
GridFieldValidationValidator — validates grid cell contents on submit
RequiredValidator — enforces dynamic required state at submit time

5 custom field renderers — registered for custom or replaced field types:

DropdownFieldRenderer — bridges five React dropdown components into Preact
GridFieldRenderer — full custom grid with Excel import, validation, and formulas
DateTimeFieldRenderer — replaces built-in datetime with rsuite DatePicker
FileUploadFieldRenderer — three-stage file handling with Camunda attachment upload
ImageViewFieldRenderer — custom image display field

Infrastructure:

CustomForm — subclasses Form, bootstraps all modules, fires form.rendered, initializes _pendingFilesRef
CustomFormEditor — subclasses FormEditor, bootstraps all editor modules
SearchableSelect — Preact searchable dropdown used throughout the properties panel
PANEL_GROUPS and FORM_EVENTS constants — shared registries for group IDs and event names
excelUtils — shared import/export utility for label/value pairs

The System Architecture

Here is every component and how they connect:

The Form Lifecycle, Step by Step

Every form session follows this sequence. Here is each step with the relevant article:

Step 1: Instantiation

const form = new CustomForm({
  container: document.getElementById('form-container'),
  // additionalModules declared inside CustomForm constructor
});

CustomForm (Article 21) calls super() with a merged options object that includes all modules. The DI container is created. All services declared in __init__ are instantiated immediately. Evaluators and validators run their constructors, subscribing to events.

At the end of the constructor, CustomForm attaches _pendingFilesRef to the event bus instance (Article 15, 18).

What's happening invisibly: The DI container resolves all $inject arrays. RequiredEvaluator.$inject = ['eventBus', 'form'] means the DI container calls new RequiredEvaluator(eventBus, form). If $inject is missing or has a typo, the parameter is undefined — the most common error in Form-JS extension development (Article 1).

Step 2: Schema Import

await form.importSchema(schema, initialData);

Form-JS reads the schema JSON and creates the Preact component tree. For each field, it looks up the registered renderer in formFields — your replacements (Article 17) win because last-registration-wins (Article 2).

The field renderers render their Preact output. For dropdown fields, the Preact renderer renders a <div id="..."> mount point and calls createRoot() to mount the React component inside it (Article 9). The reactRoots Map tracks the root for lifecycle management.

After super.importSchema() completes, CustomForm.importSchema fires form.rendered (Article 15). This signals that the DOM is ready.

Step 3: Evaluators Initialize

Each evaluator's form.init handler fires. The evaluators:

Set this._initialized = true
Call evaluateAll() after a 50ms delay
TicketAutoFillEvaluator calls _buildWatchMap() to scan the schema (Article 20)
DateTimeValidationEvaluator calls _buildDatetimeFieldRegistry() to build its Set (Article 22)

The initial evaluateAll() run applies the current state of all expressions against the pre-populated data. Fields with disabled: "= status = 'closed'" get the disabled attribute applied. Fields with conditional.hide: "= role != 'admin'" get display: none applied.

Step 4: External Context (Optional)

If the form needs ticket data for auto-fill, the application fires it into the form after import:

const eventBus = form.get('eventBus');
eventBus.fire('ticket.context.set', {
  ticket_id: currentTicket.id,
  ticket_data: currentTicket
});

TicketAutoFillEvaluator receives this via its ticket.context.set listener (Article 15, 20).

Step 5: User Interaction

The user types in a field. Form-JS updates form state. changed fires with the changed field's data.

Each evaluator's changed handler fires:

Unscoped evaluators (Article 8): DisabledEvaluator, HideEvaluator, RequiredEvaluator, PersistentEvaluator, BindingEvaluator — all check _evaluating and proceed if clear. After a 10ms debounce, evaluateAll() runs. Each checks all components, finds ones with FEEL expressions, evaluates against current form data, detects changes, updates DOM.

Scoped evaluators (Article 22): DateTimeValidationEvaluator checks whether the changed field is in _datetimeFieldKeys. If not, it returns immediately. If yes, it runs evaluation only for datetime fields with changed values.

TicketAutoFillEvaluator (Article 20): checks whether the changed field is in _watchedFields. If not, returns immediately. If yes, and the ticket selection changed, resets dependent fields, fetches from API (with cache), evaluates conditions, formats values, writes results.

Step 6: Properties Panel Changes (Editor Only)

In the form editor, when the form designer changes a property:

editField(field, path, value) is called — updates the schema
propertiesPanel.updated fires
All providers' getGroups functions run with the updated field
getOrCreateFormLogicsGroup() is called by each provider — creates or finds the Form Logics group (Article 19)
Override providers filter out replaced entries (Article 6)
All providers add their entries to the appropriate groups
The panel re-renders with the updated configuration

If the change was to a FEEL expression (say, changing disabledExpression), the dual-path setValue stores it in the schema (Article 7). On the next changed event, DisabledEvaluator reads disabledExpression, evaluates it, and applies the result.

Step 7: Validation on Submit

The user clicks Submit. Form-JS calls form.validate().

Because three validators have wrapped form.validate() with the merge-errors pattern (Article 10):

form.validate() called
  → RequiredValidator's wrapper runs
    → original validate() called
      → FeelValidator's wrapper runs
        → original validate() called
          → GridFieldValidationValidator's wrapper runs
            → actual Form-JS validate() runs
            ← returns built-in errors
          ← GridFieldValidationValidator merges grid errors
        ← FeelValidator merges FEEL errors
      ← merge
    ← RequiredValidator merges dynamic required errors
  ← return merged errors

The merged errors object is written to form state via _setState({ errors }). Fields with errors get red borders and error messages below them.

If errors exist, submission stops. If no errors, the application proceeds.

Step 8: File Upload and Submission

After successful validation, the application code:

// 1. Complete the Camunda task
await camundaClient.completeTask(taskId, { variables: formData });

// 2. Upload files from _pendingFilesRef
await form.uploadPendingFiles(taskId);

uploadPendingFiles reads eventBus._pendingFilesRef.current (the Map populated by FileUpload React components via useEffect), and posts each file to /engine-rest/task/${taskId}/attachment as multipart FormData (Article 18).

Files are uploaded after task completion — not before. If task completion fails, no orphaned attachments are created.

After upload, pendingFilesRef.current.clear() prevents double-upload on re-submit.

How Every Article Connects

Article	Component	Connects To
1 — Module System	DI container, `$inject`	All modules
2 — Custom Field Architecture	`GridFieldRenderer`, `.config`, `formFields.register`	Articles 9, 17
3 — FEEL Pipeline	`evaluate()`, JS fallback	Articles 4, 8, 10
4 — FEEL Context	`prepareContext()`, type coercion	Articles 8, 13, 20
5 — Provider Contract	`getGroups`, middleware pattern	Articles 6–7, 11–12, 19
6 — Overriding Entries	Filter + replace pattern	Articles 7, 19
7 — Toggle-or-FEEL	Dual-path getValue/setValue	Articles 6, 8
8 — Five Evaluators	Event subscription, state Map, DOM	Articles 10, 15, 22
9 — React/Preact Bridge	`reactRoots` Map, `createRoot`, generation counter	Articles 17, 18
10 — Validation Hook	`bind()`, merge-errors, `_validating`	Articles 3, 4, 8
11 — Dynamic Panels	Three conditional patterns	Articles 12, 14
12 — Cascading Config	`useEffect` deps, `editField`, per-level state	Articles 11, 14
13 — Conditional Options	`applyConditionalRules`, form data storage	Articles 3, 8
14 — SearchableSelect	Preact hooks, `onInput`, click-outside	Articles 11, 12, 16
15 — Event Bus	Custom events, `_pendingFilesRef`, registry	Articles 8, 18, 19
16 — Excel Import/Export	ExcelJS, `readAsArrayBuffer`, header detection	Articles 14
17 — DateTime Replacement	`formFields.register`, container-ref, subtypes	Articles 2, 9
18 — File Handling	`localFiles`, `_pendingFilesRef`, `uploadFileAsAttachment`	Articles 9, 15
19 — Form Logics Group	`getOrCreateFormLogicsGroup`, cooperative providers	Articles 5, 6, 15
20 — Async AutoFill	Watcher map, two-cache, context enrichment	Articles 3, 4, 8, 15
21 — CustomForm/FormEditor	Subclassing, module bootstrapping	All articles
22 — Scoped Re-evaluation	Field-type gate, Set registry, change detection	Article 8
23 — Architecture	This article	All articles

The Three Things I'd Do Differently

If I were starting this system from scratch, knowing what I know now, these are the three decisions I'd make differently.

1. Extract Shared Utilities Before Writing the Second Provider

The SearchableSelect component was written five times. The getOrCreateFormLogicsGroup function was written into six providers separately before being extracted. The FEEL evaluation pipeline was partially duplicated between evaluators. The _getAllComponents recursive function exists in nearly every evaluator.

Every duplicate was created with the same justification: "I'm not sure the API is stable yet." It's a rationalization. The real cost of not extracting is not the initial 45 minutes — it's the maintenance cost that accumulates over months. Each bug fix applied to one copy is a bug that survives in three others.

The rule I now follow: extract when you copy a second time. Not the fifth.

For a system this size, the shared utilities that should exist before you write the first provider or evaluator:

src/formjs/shared/
├── constants.ts          ← PANEL_GROUPS, FORM_EVENTS
├── panelUtils.ts         ← getOrCreateFormLogicsGroup, getOrCreateGroup
├── evaluatorUtils.ts     ← _getAllComponents, _interpretAsBoolean, _evaluateJavaScript
├── feelPipeline.ts       ← evaluate(), prepareContext(), _coerceDateValue()
├── excelUtils.ts         ← importLabelValueFromExcel, exportLabelValueToExcel
└── ui/
    └── SearchableSelect.tsx  ← The reusable component

Writing these first — before any evaluator or provider — costs two days. It saves two weeks of cleanup later.

2. Fix the React Root Race Condition From the Start

Article 9 documents the generation counter fix for the React/Preact bridge:

// When cleanup fires 150ms after unmount,
// check that the generation hasn't changed (no remount happened)
if (current.generation === capturedGeneration) {
  current.root.unmount();
}

This fix exists because I discovered the race condition three weeks after shipping the bridge. The original code — without the generation counter — caused dropdowns to disappear when Form-JS's schema update cycle unmounted and remounted the Preact renderer within 150ms.

The symptom was intermittent. It appeared when form designers updated dropdown configuration in the editor. The React root was unmounted by the stale cleanup, and the dropdown field showed a blank mount point with no error.

The root cause was knowable before shipping. The 150ms deferred cleanup was chosen to give React time to flush — but "give React time" is exactly the language that should raise a red flag. Deferred operations with fixed timeouts have race conditions. The generation counter should have been part of the original design.

The rule I now follow: any deferred operation that affects shared state needs a generation counter or equivalent cancellation mechanism.

3. Establish the Constants File Before Writing Any Provider

The Form Logics group ID 'form-logics' was a string literal in six files before I extracted it to PANEL_GROUPS.FORM_LOGICS. The event name 'required.states.changed' was a string literal in four files. The custom event names were invented ad-hoc with no consistency — some used dots (form.rendered), some used dots with subcategories (required.states.changed), one used a colon (dropdown:labelSelected).

These inconsistencies are not bugs. The system works. But they create friction:

A new developer searching for all uses of the required states event has to search for four different strings
A typo in any string literal causes a silent failure — no event fires, no error surfaces
The documentation of which events exist and who fires them is scattered across twelve files

The rule I now follow: before writing the first provider or evaluator, create constants.ts. Add every group ID and every custom event name to it before it's used anywhere. This is a thirty-minute investment that makes the system legible for the lifetime of the codebase.

The complete constants file should exist as a single source of truth and include:

// The contract for custom behavior
export const PANEL_GROUPS = { ... }    // All custom panel group IDs
export const FORM_EVENTS = { ... }     // All custom event names
export const FIELD_TYPES = { ... }     // All custom field type strings
export const SUPPORTED_FIELD_TYPES = [...] // Types that accept Form Logics entries

Four exports. Thirty minutes. Prevents a category of silent bugs for the lifetime of the project.

What the Series Covered That the Docs Don't

The official Form-JS documentation covers:

How to render a form with new Form({ ... })
The basic JSON schema for field types
A handful of examples for simple custom fields

The official documentation does not cover:

How the DI container works or how to use $inject
How to extend the properties panel beyond trivial examples
How to run FEEL expressions at runtime outside the editor
How to replace built-in field types
How to extend form.validate() without breaking it
How to coordinate multiple independent providers through a shared group
How to bridge React components into Preact renderers with production-grade lifecycle management
How to handle file uploads across framework boundaries
How to scope re-evaluation for performance in large forms

These twenty-three articles cover the gap between "I can render a form" and "I have a production-grade extension system." That gap is where most developers spend their time and find the fewest answers.

Where to Go From Here

The system documented in this series is production-deployed and maintained. The patterns are stable. But they're not the last word — there are at least three extensions that would improve the architecture:

A formal base class for evaluators. The six shared methods (_getAllComponents, _interpretAsBoolean, _evaluateJavaScript, prepareContext, _findFieldElement, evaluateAll skeleton) should be in an AbstractEvaluator class. Each concrete evaluator would extend it and implement only _hasExpression, _getExpression, _determineState, and _applyToDOM. The current duplication is the most obvious remaining technical debt.

A Web Worker for FEEL evaluation. The FEEL pipeline runs on the main thread. For forms with many fields and complex expressions, evaluation adds measurable lag to user interactions. Moving FEEL evaluation to a Web Worker would eliminate main-thread blocking entirely. The API would be asynchronous — evaluators would need to handle Promise-based evaluation results rather than synchronous returns. This is a significant architectural change but would make the system scale to arbitrarily large forms.

A TypeScript-first rewrite of the properties panel components. The properties panel components use Preact's html tagged template literals and jsx/jsxs function calls — not JSX syntax. This makes them hard to read for developers who know React and are learning the Preact properties panel system. A rewrite using Preact's JSX transform with full TypeScript types would make the component code readable, catch type errors at compile time, and make the onInput/onChange distinction explicit in the type definitions.

None of these are urgent. The system works as documented. These are improvements to make the system more maintainable as it grows.

A Note on the Camunda DevEx Application

If you've read this series because you're considering applying to Camunda's Developer Experience team: this is the portfolio.

Not the articles as writing samples — the engineering decisions documented in the articles. The decision to use the create-if-not-exists pattern for the Form Logics group rather than a central registry. The generation counter fix for the React root race condition. The scoped re-evaluation optimization. The event bus as a cross-framework data store.

These decisions were made under real constraints — production deadline, legacy code that couldn't be rewritten, browsers that had to be supported. The articles document not just what was built but why each decision was made and what the alternatives cost.

DevEx work is ultimately about making other developers' decisions easier. The best way to demonstrate that capability is to show that you've made hard decisions yourself, documented them honestly, and built something that other developers can learn from.

That's what this series is.

This is Part 23 of "Extending bpmn-io Form-JS Beyond Its Limits." The series covers the complete architecture for production-grade Form-JS extensions — the documentation that doesn't exist yet.

Index of all articles in the series:

The bpmn-io Form-JS Module System: Dependency Injection Nobody Explains
Building Your First Custom Field in Form-JS: The Complete Four-Layer Architecture
FEEL at Runtime in Form-JS: Building an Expression Evaluation Pipeline from Scratch
Preparing a FEEL Context: The Type Coercion Problem Nobody Warns You About
The Properties Panel Provider Contract: What the Official Docs Leave Out
Overriding Default Properties Panel Entries: How to Replace What Form-JS Ships With
The Toggle-or-FEEL Pattern: Properties That Can Be Static or Dynamic
Five Evaluators, One Pattern: Scaling Conditional Logic Across a Form
React Inside Preact: Mounting React Components in a Form-JS Renderer
Hooking Into Form Validation Without Breaking It: The Merge-Errors Pattern
Dynamic Properties Panels: Three Patterns for Conditional Entry Display
Cascading Configuration UI: Building Dependent Selection Chains in the Properties Panel
The Conditional Options Algorithm: Priority Mode vs Merge Mode
Building a Searchable Select Component for the bpmn-io Properties Panel
Using the Form-JS Event Bus as an Application Communication Layer
Excel Import and Export in the bpmn-io Properties Panel
Replacing a Built-In Field Type: Swapping Form-JS DateTime with rsuite DatePicker
File Handling Across the Form Lifecycle: From Selection to Camunda Task Attachment
The Form Logics Group: Building a Cross-Provider Panel Section
Async AutoFill With Caching: Filling Form Fields From External APIs at Runtime
Subclassing Form and FormEditor: Building a Custom Runtime Foundation
Scoped Re-evaluation: Preventing Unnecessary FEEL Expression Evaluation in Large Forms
The Full Architecture: How a Form-JS Extension System Fits Together

Tags: camunda bpmn formjs architecture series-capstone javascript devex

Scoped Re-evaluation: Preventing Unnecessary FEEL Expression Evaluation in Large Forms

Sam Abaasi — Wed, 29 Apr 2026 06:33:11 +0000

Part 22 of the series: "Extending bpmn-io Form-JS Beyond Its Limits"

The evaluator pattern from Article 8 has a performance assumption built into it: when changed fires, re-evaluate everything. For small forms this is fine. For a form with 50 fields that loads pre-populated data, it's a problem.

When Form-JS loads pre-populated data, it writes each field's value into form state. Each write fires a changed event. A 50-field form fires 50 changed events on load. If you have five evaluators, each one re-evaluating all 50 components on every event, that's 50 × 5 × 50 = 12,500 evaluations on load. Most of them evaluate the same expressions against the same data they already evaluated 10ms ago.

This article documents the DateTimeValidationEvaluator as a case study in scoped re-evaluation — an evaluator that fires only when relevant fields change, filters its context to only relevant data, and skips _setState calls when nothing changed. Then it generalizes the pattern to a template you can apply to any type-specific evaluator.

The Problem at Scale

To understand why scope matters, trace what happens when a 50-field form loads:

Form loads with pre-populated data
  → form.init fires (evaluators initialize)
  → Form-JS writes field 1 value → changed fires
     DisabledEvaluator.evaluateAll() runs: 50 components × FEEL eval = 50 evals
     HideEvaluator.evaluateAll() runs: 50 components × FEEL eval = 50 evals
     RequiredEvaluator.evaluateAll() runs: 50 components × FEEL eval = 50 evals
     BindingEvaluator.evaluateAll() runs: 50 components × FEEL eval = 50 evals
     DateTimeValidationEvaluator.evaluateAll() runs: 50 components × FEEL eval = 50 evals
     Total: 250 FEEL evaluations
  → Form-JS writes field 2 value → changed fires
     Same: 250 FEEL evaluations
  ...
  → Form-JS writes field 50 value → changed fires
     Same: 250 FEEL evaluations

Total on load: 50 events × 250 evaluations = 12,500 FEEL evaluations

FEEL evaluation is not free. The feelin library parses the expression, builds an AST, evaluates it against the context. A complex expression with multiple variables takes 1-5ms. Twelve thousand evaluations at 1ms each is 12 seconds of JavaScript execution blocking the UI thread.

In practice, most expressions are simple (= status = "closed", = amount > 1000) and feelin is fast. The observed performance cost is more like 200-500ms for a 50-field form — noticeable but not catastrophic. But for forms with 100+ fields, or evaluators with expensive evaluation logic (like DateTimeValidationEvaluator which needs to parse date strings and compare Date objects), the cost accumulates.

The DateTimeValidationEvaluator is the clearest case for scoped re-evaluation because datetime validation has a very narrow scope: it only matters when a datetime field changes. If the user types in a text field, no datetime validation needs to run.

The Baseline Evaluator (Without Optimization)

For comparison, here is what DateTimeValidationEvaluator would look like following the standard pattern from Article 8, without any scoping:

// ❌ Unscoped — re-evaluates everything on every changed event

export class DateTimeValidationEvaluator {
  constructor(eventBus, form) {
    this._eventBus = eventBus;
    this._form = form;
    this._evaluating = false;
    this._initialized = false;
    this._validationErrors = {};

    this._eventBus.on('form.init', () => {
      this._initialized = true;
      setTimeout(() => this.evaluateAll(), 50);
    });

    // ❌ Fires on EVERY field change — even text fields, dropdowns, checkboxes
    this._eventBus.on('changed', () => {
      if (!this._initialized || this._evaluating) return;
      setTimeout(() => {
        if (!this._evaluating) this.evaluateAll();
      }, 10);
    });
  }

  evaluateAll() {
    this._evaluating = true;
    try {
      const schema = this._form._state.schema;
      const data = this._form._state.data || {};
      const components = this._getAllComponents(schema.components || []);

      // ❌ Iterates ALL 50+ components to find datetime fields
      const datetimeComponents = components.filter(c =>
        ['date', 'datetime', 'time'].includes(c.type) && c.key
      );

      // Evaluate validation for each datetime component
      // ...
    } finally {
      this._evaluating = false;
    }
  }
}

On a 50-field form with 3 datetime fields, this evaluator:

Runs 50 times during pre-population (once per field)
Each run iterates all 50 components to find the 3 datetime ones
Then evaluates validation expressions for those 3 fields
Total: 50 × 50 iterations + 50 × 3 FEEL evaluations = 2,650 operations

Most of those operations happen because text fields, dropdowns, and checkboxes changed — events that have nothing to do with datetime validation.

Optimization 1: Field-Type Gating

The first optimization: check whether the changed field is a datetime field before doing anything:

// ✅ Field-type gating — skip evaluation when irrelevant fields change

this._eventBus.on('changed', (event) => {
  if (!this._initialized || this._evaluating) return;

  // ✅ Extract what changed from the event
  const changedData = event.data || {};
  const changedKeys = Object.keys(changedData);

  // ✅ Check if any datetime field changed
  const hasDatetimeChange = changedKeys.some(key =>
    this._isDatetimeField(key)
  );

  // ✅ Skip entirely if no datetime field changed
  if (!hasDatetimeChange) return;

  setTimeout(() => {
    if (!this._evaluating) this.evaluateAll();
  }, 10);
});

The _isDatetimeField check:

_isDatetimeField(fieldKey) {
  if (!this._form?._state?.schema) return false;

  // ✅ Check by schema ID (the component's id property)
  // Sometimes changed fires with the component's id, not its key
  const allComponents = this._getAllComponents(
    this._form._state.schema.components || []
  );

  const component = allComponents.find(c => c.key === fieldKey || c.id === fieldKey);
  if (!component) return false;

  return ['date', 'datetime', 'time'].includes(component.type);
}

The check iterates all components to find one by key or ID. For a 50-component form this is fast — a simple array scan. The cost is much lower than running FEEL evaluation.

With field-type gating, the 50-field form pre-population becomes:

50 changed events fire during pre-population
  → 3 events: datetime field changed → evaluateAll() runs
  → 47 events: non-datetime fields changed → skip (early return)

Total: 3 evaluations instead of 50

An 83% reduction in evaluation runs.

Optimization 2: Schema-Based Field Registry

The _isDatetimeField check scans all components on every changed event. For a large form, this adds up. Build the datetime field set once on form.init instead:

// ✅ Build a Set of datetime field keys on init

_datetimeFieldKeys = new Set();

_buildDatetimeFieldRegistry() {
  this._datetimeFieldKeys.clear();

  if (!this._form?._state?.schema) return;

  const components = this._getAllComponents(
    this._form._state.schema.components || []
  );

  components.forEach(component => {
    if (['date', 'datetime', 'time'].includes(component.type) && component.key) {
      this._datetimeFieldKeys.add(component.key);
      // Also add by id in case events use id instead of key
      if (component.id) this._datetimeFieldKeys.add(component.id);
    }
  });
}

// ✅ O(1) lookup instead of O(n) scan
_isDatetimeField(fieldKey) {
  return this._datetimeFieldKeys.has(fieldKey);
}

Initialize on form.init and rebuild when the schema changes:

this._eventBus.on('form.init', () => {
  this._initialized = true;
  this._buildDatetimeFieldRegistry();
  setTimeout(() => this.evaluateAll(), 50);
});

this._eventBus.on('propertiesPanel.updated', () => {
  // Schema may have changed (new datetime field added or removed)
  this._buildDatetimeFieldRegistry();

  if (!this._initialized || this._evaluating) return;
  setTimeout(() => {
    if (!this._evaluating) this.evaluateAll();
  }, 50);
});

Now _isDatetimeField(key) is a Set lookup — O(1) regardless of form size.

Optimization 3: Context Filtering

The standard evaluator pattern builds a context from all form data. DateTimeValidationEvaluator's FEEL expressions reference other datetime fields — = value >= today(), = startDate <= endDate. They never reference text fields, dropdowns, or checkboxes.

Filtering the context to only datetime values makes evaluation faster and prevents irrelevant data from polluting the FEEL context:

// ❌ Full context — 50+ values, most irrelevant
prepareContext(data) {
  const context = {};
  Object.keys(data).forEach(key => {
    context[key] = this._coerceValue(data[key]);
  });
  context.today = () => { ... };
  context.now = () => new Date();
  return context;
}

// ✅ Filtered context — only datetime values + date helpers
_getRelevantFormData(data) {
  const context = {};

  // Only include datetime field values
  this._datetimeFieldKeys.forEach(fieldKey => {
    if (data[fieldKey] !== undefined) {
      // ✅ Convert string dates to Date objects for FEEL comparison
      const converted = this._coerceDateValue(data[fieldKey]);
      context[fieldKey] = converted !== null ? converted : data[fieldKey];
    }
  });

  // ✅ Current field's value available as 'value'
  // (set per-component during evaluation)

  // ✅ Date/time helpers always available
  context.today = () => {
    const d = new Date();
    d.setHours(0, 0, 0, 0);
    return d;
  };
  context.now = () => new Date();
  context.tomorrow = () => {
    const d = new Date();
    d.setDate(d.getDate() + 1);
    d.setHours(0, 0, 0, 0);
    return d;
  };
  context.yesterday = () => {
    const d = new Date();
    d.setDate(d.getDate() - 1);
    d.setHours(0, 0, 0, 0);
    return d;
  };

  return context;
}

Why smaller context helps FEEL evaluation: feelin builds a lookup table for each variable name in the expression and resolves it against the context. A context with 50 keys has 50 lookups to manage. A context with 5 keys has 5. The difference is small per evaluation but adds up across thousands of evaluations.

More importantly, a smaller context prevents accidental matches. If a text field has a key of startDate and the FEEL expression references startDate, a full-context evaluator would include the text field's string value. The filtered-context evaluator only includes values from actual datetime fields.

The `_coerceDateValue` Method

DateTime validation evaluates expressions like = value >= today(). For this comparison to work in FEEL, value must be a Date object, not the string "2024-01-15" that's stored in form data.

The coercion converts stored strings to Date objects:

_coerceDateValue(rawValue, type = 'date') {
  if (!rawValue || typeof rawValue !== 'string') return null;

  const v = rawValue.trim();
  if (!v) return null;

  try {
    if (type === 'date' || /^\d{4}-\d{2}-\d{2}$/.test(v)) {
      // "2024-01-15" → Date at local midnight
      return new Date(v + 'T00:00:00');
    }

    if (type === 'datetime' || /^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}$/.test(v)) {
      // "2024-01-15 10:30:00" → Date (space to T)
      return new Date(v.replace(' ', 'T'));
    }

    if (type === 'time' || /^\d{2}:\d{2}:\d{2}$/.test(v)) {
      // "10:30:00" → keep as string (time comparison is string comparison)
      return v;
    }
  } catch (err) {
    console.warn(`[DateTimeValidationEvaluator] Could not coerce value: ${v}`);
    return null;
  }

  return null;
}

The T00:00:00 suffix for date-only strings prevents the timezone offset problem from Article 17: new Date('2024-01-15') parses as UTC midnight and shifts to the previous day in negative UTC offsets. new Date('2024-01-15T00:00:00') parses as local midnight.

Optimization 4: Change Detection on Results

Even when evaluation runs, the results might be identical to the previous run. Writing identical errors to form state via _setState triggers a re-render, which triggers another changed event, which could trigger evaluation again.

Track the last evaluated values and skip _setState when nothing changed:

_lastEvaluatedValues = {};
_lastValidationErrors = {};

evaluateAll() {
  if (!this._form?._state?.schema) return;

  this._evaluating = true;

  try {
    const schema = this._form._state.schema;
    const data = this._form._state.data || {};
    const allComponents = this._getAllComponents(schema.components || []);

    const datetimeComponents = allComponents.filter(c =>
      this._datetimeFieldKeys.has(c.key) && c.key
    );

    if (!datetimeComponents.length) return;

    // ✅ Get filtered context once — reuse for all components
    const baseContext = this._getRelevantFormData(data);

    const newErrors = {};
    let hasChanges = false;

    datetimeComponents.forEach(component => {
      const key = component.key;
      const rawValue = data[key];

      // ✅ Check if this field's value changed since last evaluation
      if (this._lastEvaluatedValues[key] === rawValue) {
        // Value hasn't changed — reuse previous error state
        if (this._lastValidationErrors[key]) {
          newErrors[key] = this._lastValidationErrors[key];
        }
        return; // Skip re-evaluation for this component
      }

      // ✅ Value changed — run evaluation
      const coercedValue = this._coerceDateValue(rawValue, component.type);
      const componentContext = {
        ...baseContext,
        value: coercedValue   // 'value' always refers to this field's value
      };

      const componentErrors = this._validateDatetimeComponent(
        component,
        componentContext,
        rawValue
      );

      if (componentErrors.length > 0) {
        newErrors[key] = componentErrors;
      }

      // ✅ Track what we evaluated
      this._lastEvaluatedValues[key] = rawValue;
      this._lastValidationErrors[key] = componentErrors.length > 0
        ? componentErrors
        : null;

      // ✅ Check if the error state actually changed
      const prevErrors = this._lastValidationErrors[key];
      const prevHadError = prevErrors && prevErrors.length > 0;
      const nowHasError = componentErrors.length > 0;
      if (prevHadError !== nowHasError || JSON.stringify(prevErrors) !== JSON.stringify(componentErrors)) {
        hasChanges = true;
      }
    });

    // ✅ Only update form state if errors actually changed
    if (hasChanges) {
      const currentErrors = this._form._state.errors || {};
      const mergedErrors = { ...currentErrors };

      // Remove old datetime errors and add new ones
      datetimeComponents.forEach(c => {
        if (newErrors[c.key]) {
          mergedErrors[c.key] = newErrors[c.key];
        } else {
          delete mergedErrors[c.key];
        }
      });

      this._form._setState({ errors: mergedErrors });
      this._validationErrors = newErrors;
    }
  } catch (err) {
    console.error('[DateTimeValidationEvaluator] Error:', err);
  } finally {
    this._evaluating = false;
  }
}

What _lastEvaluatedValues tracks: For each datetime field, the last raw string value that was evaluated. If the current value matches the tracked value, evaluation is skipped and the previous error state is reused. Only fields whose values changed since the last evaluation run.

On a 50-field form after pre-population completes, all 3 datetime fields have been evaluated and their values tracked. When the user types in a text field (triggering changed), the field-type gate catches it first and skips the evaluator entirely. When the user changes a datetime field, only that field's value differs from _lastEvaluatedValues — the other two datetime fields are skipped.

The Validation Logic

The evaluation itself checks configured validation rules:

_validateDatetimeComponent(component, context, rawValue) {
  const errors = [];

  if (!rawValue) {
    // Empty values are handled by RequiredValidator — not our responsibility
    return errors;
  }

  // ✅ Basic format validation first
  const formatError = this._validateDatetimeFormat(rawValue, component.type);
  if (formatError) {
    errors.push(formatError);
    return errors; // Don't run FEEL validation on invalid format
  }

  // ✅ Run configured FEEL validation rules
  const validationRules = component.validate?.customValidations || [];

  for (const rule of validationRules) {
    if (!rule.expression) continue;

    try {
      const result = this._evaluateFeel(rule.expression, context);
      const isValid = !!result;

      if (!isValid) {
        errors.push(rule.message || `Validation failed for ${component.label || component.key}`);
      }
    } catch (err) {
      console.error(
        `[DateTimeValidationEvaluator] Error evaluating rule for ${component.key}:`,
        err.message
      );
    }
  }

  return errors;
}

_validateDatetimeFormat(value, type) {
  if (!value || typeof value !== 'string') return null;

  if (type === 'date' && !/^\d{4}-\d{2}-\d{2}$/.test(value)) {
    return `Invalid date format. Expected YYYY-MM-DD, got: ${value}`;
  }

  if (type === 'datetime' && !/^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}$/.test(value)) {
    return `Invalid datetime format. Expected YYYY-MM-DD HH:mm:ss`;
  }

  if (type === 'time' && !/^\d{2}:\d{2}:\d{2}$/.test(value)) {
    return `Invalid time format. Expected HH:mm:ss`;
  }

  return null; // Format is valid
}

Format validation runs before FEEL validation. If the stored value is "15-01-2024" (wrong format), there's no point running FEEL expressions that expect a parseable date — _coerceDateValue would return null, and = value >= today() would evaluate to null (not false), producing no error when there should be one. Format validation catches the upstream problem first.

Measured Performance

For a form with 50 fields (3 datetime fields) loading with pre-populated data:

Baseline (unscoped):

50 changed events on load
50 evaluator runs
Each run: iterate 50 components + evaluate 3 datetime fields
Total operations: 50 × (50 + 3) = 2,650

With field-type gating only:

50 changed events on load
3 evaluator runs (only datetime field changes pass the gate)
Each run: iterate 50 components + evaluate 3 datetime fields
Total operations: 3 × (50 + 3) = 159

With field-type gating + Set registry:

3 evaluator runs
Each run: 3 × O(1) Set lookups + evaluate 3 datetime fields
Total operations: approximately 3 × (3 + 3) = 18

With all optimizations (gating + Set + context filtering + change detection):

3 evaluator runs
First run evaluates all 3 datetime fields: 3 FEEL evaluations
Subsequent runs for unchanged datetime fields: 0 FEEL evaluations (change detection skips)
Total FEEL evaluations on load: 3

The reduction from 2,650 to ~18 operations is approximately 99% for the load phase. For a 100-field form with 5 datetime fields, the baseline would be 5,000+ operations; the optimized version stays at ~5.

During active use (user filling the form), each datetime field change triggers at most 1 FEEL evaluation for the changed field and 0 for unchanged datetime fields. Text field changes trigger 0 evaluations.

The General Pattern: Field-Type Gating Template

Any evaluator that only cares about specific field types should implement these four optimizations. Here is the template:

// ScopedEvaluator.js — template for type-specific evaluators

export class ScopedEvaluator {
  constructor(eventBus, form) {
    this._eventBus = eventBus;
    this._form = form;
    this._evaluating = false;
    this._initialized = false;

    // ✅ Optimization 1 + 2: Type registry
    this._relevantFieldKeys = new Set();

    // ✅ Optimization 4: Change detection
    this._lastEvaluatedValues = {};
    this._lastResults = {};

    this._feelEngine = null;
    try {
      this._feelEngine = { evaluate };
    } catch (err) {
      console.warn('[ScopedEvaluator] FEEL engine unavailable');
    }

    // Initialize
    this._eventBus.on('form.init', () => {
      this._initialized = true;
      this._buildFieldRegistry();
      setTimeout(() => this.evaluateAll(), 50);
    });

    // ✅ Optimization 1: Field-type gate on changed
    this._eventBus.on('changed', (event) => {
      if (!this._initialized || this._evaluating) return;

      const changedKeys = Object.keys(event.data || {});
      const hasRelevantChange = changedKeys.some(k => this._relevantFieldKeys.has(k));

      if (!hasRelevantChange) return; // ✅ Skip — no relevant fields changed

      setTimeout(() => {
        if (!this._evaluating) this.evaluateAll();
      }, 10);
    });

    // Rebuild registry when schema changes
    this._eventBus.on('propertiesPanel.updated', () => {
      this._buildFieldRegistry();
      if (!this._initialized || this._evaluating) return;
      setTimeout(() => {
        if (!this._evaluating) this.evaluateAll();
      }, 50);
    });

    // Re-apply after render
    this._eventBus.on('form.rendered', () => {
      setTimeout(() => this._applyToDOM(), 50);
    });
  }

  // ✅ Optimization 2: Build Set of relevant field keys
  _buildFieldRegistry() {
    this._relevantFieldKeys.clear();

    if (!this._form?._state?.schema) return;

    const components = this._getAllComponents(
      this._form._state.schema.components || []
    );

    components.forEach(component => {
      // ✅ Replace with your relevant types
      const RELEVANT_TYPES = ['date', 'datetime', 'time']; // example

      if (RELEVANT_TYPES.includes(component.type)) {
        if (component.key) this._relevantFieldKeys.add(component.key);
        if (component.id) this._relevantFieldKeys.add(component.id);
      }
    });
  }

  evaluateAll() {
    if (!this._form?._state?.schema) return;

    this._evaluating = true;

    try {
      const schema = this._form._state.schema;
      const data = this._form._state.data || {};
      const allComponents = this._getAllComponents(schema.components || []);

      // Only process relevant components
      const relevantComponents = allComponents.filter(c =>
        this._relevantFieldKeys.has(c.key) && c.key
      );

      if (!relevantComponents.length) return;

      // ✅ Optimization 3: Build filtered context once
      const baseContext = this._getFilteredContext(data);

      let hasChanges = false;

      relevantComponents.forEach(component => {
        const key = component.key;
        const rawValue = data[key];

        // ✅ Optimization 4: Skip if value hasn't changed
        if (this._lastEvaluatedValues[key] === rawValue) {
          return; // Nothing to do for this component
        }

        // Evaluate this component
        const result = this._evaluateComponent(component, baseContext, rawValue, data);

        // Check if result changed
        if (JSON.stringify(result) !== JSON.stringify(this._lastResults[key])) {
          hasChanges = true;
          this._lastResults[key] = result;
        }

        this._lastEvaluatedValues[key] = rawValue;
      });

      // ✅ Only apply if something changed
      if (hasChanges) {
        this._applyResults();
        this._applyToDOM();
      }
    } catch (err) {
      console.error('[ScopedEvaluator] Error:', err);
    } finally {
      this._evaluating = false;
    }
  }

  // ✅ Optimization 3: Filter context to relevant fields only
  _getFilteredContext(data) {
    const context = {};

    this._relevantFieldKeys.forEach(fieldKey => {
      if (data[fieldKey] !== undefined) {
        context[fieldKey] = this._coerceValue(data[fieldKey]);
      }
    });

    // Add any helpers needed by your FEEL expressions
    context.today = () => { const d = new Date(); d.setHours(0,0,0,0); return d; };
    context.now = () => new Date();

    return context;
  }

  // Implement these for your specific use case:

  _evaluateComponent(component, baseContext, rawValue, data) {
    // Your evaluation logic here
    return null;
  }

  _coerceValue(value) {
    // Convert stored values to FEEL-compatible types
    return value;
  }

  _applyResults() {
    // Write results to form state
  }

  _applyToDOM() {
    // Apply DOM changes if needed
  }

  // Standard utilities
  _getAllComponents(components = []) {
    const all = [];
    for (const c of components) {
      all.push(c);
      if (c.type === 'group' && Array.isArray(c.components)) {
        all.push(...this._getAllComponents(c.components));
      }
    }
    return all;
  }
}

ScopedEvaluator.$inject = ['eventBus', 'form'];

When to Scope vs When to Evaluate Everything

Not all evaluators benefit from scoping. The decision depends on two factors:

Factor 1: What triggers the evaluator?

If your evaluator only needs to run when fields of a specific type change, scope it. If it needs to run when any field changes (like DisabledEvaluator — any field change might affect whether another field should be disabled), don't scope it.

Factor 2: How expensive is evaluation?

If evaluation is cheap (simple boolean expression, no API calls), the overhead of scoping might exceed the savings. If evaluation is expensive (parsing date strings, comparing Date objects, running multiple rules per field), scoping pays off quickly.

For the evaluators in this series:

Evaluator	Scope By Type?	Reason
BindingEvaluator	No	Any field can affect any computed binding
DisabledEvaluator	No	Any field can affect any other field's disabled state
HideEvaluator	No	Any field can affect any other field's visibility
RequiredEvaluator	No	Any field can affect any other field's required state
PersistentEvaluator	No	Any field can affect persistent state
DateTimeValidationEvaluator	Yes	Only datetime changes affect datetime validation
TicketAutoFillEvaluator	Yes (watcher map)	Only watched fields trigger auto-fill

TicketAutoFillEvaluator uses the watcher map pattern (Article 20) rather than field-type gating — it's scoped by configuration rather than type. The result is the same: only relevant changes trigger evaluation.

The Tradeoffs

The _lastEvaluatedValues cache can go stale. If a FEEL expression references external state — context.today(), form data from other fields included via the base context — the expression result might change even though the field's raw value hasn't. The _lastEvaluatedValues guard would incorrectly skip re-evaluation.

For DateTimeValidationEvaluator, this is handled by the context filtering: the base context includes other datetime fields, and if those change, they pass the field-type gate and trigger a full evaluateAll() run. The _lastEvaluatedValues guard then re-evaluates only the fields whose values changed.

For evaluators where the context depends on fields outside the scoped set, the _lastEvaluatedValues optimization is unsafe. In that case, use the field-type gate and context filtering but skip the per-value change detection.

The Set registry must be rebuilt when the schema changes. If the form designer adds a new datetime field while the editor is open, _relevantFieldKeys won't include it until _buildFieldRegistry() runs on the next propertiesPanel.updated event. During the window between field addition and registry rebuild, the new field won't receive validation. The 50ms delay on propertiesPanel.updated makes this window longer than necessary. Shortening it (or eliminating the delay) would reduce the window at the cost of potential redundant rebuilds.

JSON.stringify for result comparison has edge cases. For complex result objects (arrays with nested objects), JSON.stringify can produce different strings for equivalent objects if key order differs. For the simple result types used in datetime validation (arrays of strings, booleans, null), this is not a problem in practice.

What Comes Next

Scoped re-evaluation is the performance layer on top of the evaluator pattern. Combined with the caching in TicketAutoFillEvaluator (Article 20), these two articles address the main performance concerns in a large-form extension system.

Article 23 — the capstone — ties everything together: the complete system architecture, the full lifecycle from form instantiation to submission, and the three things I would do differently if starting over.

This is Part 22 of "Extending bpmn-io Form-JS Beyond Its Limits." The series covers the complete architecture for production-grade Form-JS extensions — the documentation that doesn't exist yet.

Tags: camunda bpmn formjs performance feel optimization runtime-evaluation javascript devex

Forem: Sam Abaasi

The Trap of Perfectionism: Do Easy Peasy Lemon Squeezy

Drafts Everywhere

What I Was Perfectionist About

The Thing Jack Harrington Says

I Cut the Code. I Kept the Story.

What Finally Got Published

The Real Lesson

How React Works (Part 9)? The Complete Picture: From a Keystroke to a Pixel

The Complete Picture: From a Keystroke to a Pixel

Eight Articles. One Question.

The User

The Page Loads

She Types "h"

The Results Need to Update

React Finds What Changed

The DOM Updates

She Clicks "Add to Cart"

What Didn't Run

The Complete Map

What's Still Being Built

The One-Sentence Answer

What You Actually Have Now

🙏 Thank You

How React Works (Part 8)? Server Components & Hydration: The Real Story

Server Components & Hydration: The Real Story

Where We Left Off

The Problem Nobody Talks About

The Problem: The Two-Trip Lie

What Hydration Actually Is — and What's Wrong With It

What Server Components Actually Are

The Security Reality: React2Shell

A Concrete Trace: What Actually Happens on Navigation

The Vibe Coding RSC Trap

When You Don't Need Server Components

The One-Sentence Rule

What's Coming in Part 9

🎬 Watch These

🙏 Sources & Thanks

How React Works (Part 7)? The Trap of Vibe Coding `useCallback`

The Trap of Vibe Coding useCallback

Where We Left Off

You Wrapped Everything in useCallback. You Added React.memo to Every Component. Your App Is Still Slow. What Went Wrong?

React's Default: Re-render Everything, Skip What It Can

Every Render Creates New References Without You Noticing

The Part Nobody Tells You: Children Re-render Even With No Props

The Free Fix: Children as Props

When You Actually Need React.memo

What useCallback and useMemo Actually Do — From the Source

The Hidden Cost: What Happens on Every Render

The Vibe Coding Trap

The Right Order

A Note on the React Compiler

What's Coming in Part 8

🎬 Watch These

🙏 Sources & Thanks

How React Works (Part 6)? How State Actually Works: useState from the Inside

How State Actually Works: useState from the Inside

Three Things That Confuse Almost Everyone

Where State Lives

What Happens When You Call setState

A Concrete Trace: One Button Click

Why You See the Old Value After setState

Why Three setCount Calls Only Increment Once

Why Multiple setState Calls Don't Cause Multiple Re-renders

The Same-Value Optimization (and Its Catch)

useRef: State Without Re-renders

The Full Picture

What's Coming in Part 7

🎬 Watch These

🙏 Sources & Thanks

How React Works (Part 5)? The React Lifecycle From the Inside: When Things Actually Run

The React Lifecycle From the Inside: When Things Actually Run

A Puzzle Most React Developers Get Wrong

The Three Phases of a React Render

What useEffect Actually Is

The Cleanup: Why It Runs Before the Next Effect

useLayoutEffect: The Synchronous Version

The "After Paint" Rule Has an Exception

The Dependency Array: What It Actually Controls

The Trap of Vibe Coding `useCallback`

You Wrapped Everything in `useCallback`. You Added `React.memo` to Every Component. Your App Is Still Slow. What Went Wrong?

When You Actually Need `React.memo`

What `useCallback` and `useMemo` Actually Do — From the Source

What Happens When You Call `setState`

Why You See the Old Value After `setState`

Why Three `setCount` Calls Only Increment Once

Why Multiple `setState` Calls Don't Cause Multiple Re-renders

`useRef`: State Without Re-renders

What `useEffect` Actually Is

`useLayoutEffect`: The Synchronous Version

Start With Something You Already Know: `throw`

The Problem With `try / catch`: No Coming Back

Algebraic Effects: A Resumable `try / catch`

What makes this more powerful than `try / catch`

The List Problem: Why `key` Exists