From a JSON file to the screen

The browser draws the DOM, the tree of element objects it built from our HTML (the HTML to pixels page follows that tree to the screen). Our JavaScript variables live somewhere else entirely, in the engine's memory. Nothing connects them: count++ changes a number in memory, and the screen stays exactly as it was until some code writes to the DOM.

In plain JavaScript that code is ours. The script runs once, top to bottom, so a variable declared at the top keeps its value for the life of the page. A click handler runs again on every click, changes the variable, and then must also change the DOM element that shows it.

A React component is a function, and React calls it whenever it needs to know what the screen should look like. That call is a render. Changing the real DOM to match is the commit. Each render is a fresh function call, so let count = 0 inside the component is created again, set to 0, every time.

So the value has to live outside our function. React keeps one object per component instance, a fiber, and on it a list of hooks in call order. The first time useState runs, mountStateImpl makes a hook, stores our starting value in hook.memoizedState, and mountState returns it with a dispatch function bound to this fiber. That pair is the [count, setCount] we destructure. On later renders useState ignores the starting value and returns what the slot holds.

Calling setCount runs dispatchSetStateInternal. Usually it queues the update and calls scheduleUpdateOnFiber: that is the request to render again. But first it may try a shortcut. If nothing else is pending on this fiber or its alternate (the copy from the previous render), it computes the new state right away and compares it with Object.is. Equal means there is nothing to do, and React returns without scheduling a render.

The line useEffect(() => { … }, []) holds two functions. useEffect itself is called during the render: the brackets after its name call it. Our arrow function is only passed to it as a value, like the function we pass to setTimeout(fn, 1000) or button.addEventListener("click", fn). Those calls run now and keep fn for later; useEffect does the same.

On the first render, mountEffectImpl receives our arrow as create and pushes it onto the fiber's effect list, flagged HookHasEffect ("run me"). There is no create() anywhere in it. After the commit has changed the DOM, commitHookEffectListMount walks that list and, for every effect with the flag, finally calls create(). That is the moment our fetch starts. Waiting until then means the page (here, the spinner) is already on screen, and React can check the dependency array on later renders before deciding whether to run the effect at all.

This is the version of our Technologies section that keeps the data in useState and fetches in an effect (the full file is in Frame 5). Step through it. The lit lines are the ones running; on the right are the values React holds, the state of the effect, the network, and the screen.

On every render after the first, updateEffectImpl runs instead. If we passed an array, it hands this render's array and the previous one to areHookInputsEqual, which walks them item by item with is, React's name for Object.is. All equal: the effect is pushed without HookHasEffect, and the commit skips it. Anything different, or no array at all (nextDeps is null, so the comparison is never made): the flag is set and the effect runs after the commit.

So the array holds the values our effect reads: state, props, or anything computed from them. React's rule is that every such value belongs in it. Our fetch reads nothing that can change (a fixed file name), so [] is correct, and with an empty array the loop has nothing to compare and always answers "equal".

use, added in React 19, reads a value from a promise during render. It first checks that it was given a "thenable" (an object with a .then method), then trackUsedThenable looks at a property React writes onto the promise itself: status. If it says "fulfilled", use returns value straight away. If the promise has no status yet, React sets it to "pending", attaches its own .then that will write status and value when the promise settles, and then throws SuspenseException. Our component stops on that line; the rest of it never runs.

The throw unwinds React's work loop up to the nearest <Suspense>, which renders its fallback instead, and React commits that. It also attaches a ping listener to the same promise. When the promise settles, pingSuspendedRoot marks the root and schedules a render. React then calls our component again from the top; this time status is "fulfilled", so use returns the data.

Because React re-runs the component rather than resuming it, the promise must be the same object on the retry: only that object carries status: "fulfilled". In our file it is created once, at the top level, when the module first runs. If we wrote use(loadTechnologies()) inside the component, each retry would make a brand-new promise with no status, start another request, and suspend again, forever. Real React does exactly that: 22 requests in two seconds and the spinner never leaves (Real output). React's development warning "A component was suspended by an uncached promise" fires only when it re-runs the same render attempt and sees a different promise at the same position; in this loop each attempt is new, so we saw no warning at all.

One step real React takes that our first sketch missed: right after committing the fallback, React 19 renders the suspended part once more, while the promise is still pending, to warm up siblings it skipped during the unwind. use throws again and nothing on screen changes. The lab shows it as its own step, because real React logs it.

Both files load public/Technologies.json (Vite serves public/ at / during development and copies it unchanged into dist/ when we build, so the same URL works after deploying). They show the same spinner, then the same grid. What differs is who does each job.

Why async goes on a helper, never on the component or the effect. An async function always returns a promise. A component in the browser must return JSX, not a promise (React 19 throws "async Client Component" when it detects one), and an effect function may return only nothing or a cleanup function. So both versions put async on loadTechnologies and call it.

The blank page we hit while writing this. The file was public/Technologies.json, and the code fetched /technologies.json. Windows file names ignore case; URLs do not, and neither does Vite's list of public files or a Linux server like Netlify's. The server answered with a 404 page, res.json() failed on its first character ("Unexpected token '<', "<!doctype "... is not valid JSON"), the promise rejected, use threw that error, and with no error boundary to catch it React removed the whole tree. Real React does exactly this in our check. The name in fetch must match the file name exactly.

Each line below was logged by real React 19.2.8 in Chromium running our two components, with the server answering after 300 ms. A MutationObserver adds a highlighted line each time a commit changed the screen. The production build is what npm run build ships; the development build with <StrictMode> is what npm run dev gives us.

Five questions in the style of a web engineering exam. Write our answer first, then open the model answer and mark ourselves honestly. Orders and counts in the answers come from the verified labs and the captured real React output.