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

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