Fetch-on-render makes a waterfall
Posts start at 500 ms, after the user arrived, so the page needs 1000 ms for two 500 ms requests. (Times are rounded to 500 ms. A real project with StrictMode would also log each start twice in development: Topic 7.4.)
React apps load data in four main ways: in effects, through a data library, in route loaders, or in server components; the big difference between them is when a request starts, and starting late causes slow request waterfalls.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
A Dashboard renders <Stats /> and <Alerts />; each fetches in its own effect. Is this a waterfall? Explain, then write a version where Alerts only renders after stats load and say what changes.
Rewrite this to start both requests at once: const user = await getUser(id); const orders = await getOrders(id);.
Write a React Router route object with a loader that loads a product and its reviews in parallel, and the component that reads them.
Explain it without notes
Name the four main ways a React app gets data and one strength and one weakness of each.
What is a request waterfall, why do effects tend to create them, and how do you fix one?
Explain fetch-on-render, fetch-then-render and render-as-you-fetch.
Why does React's documentation steer people away from fetching in effects for production apps?
Preview
Console
Nothing logged yet.Expected console output
start user at 0 ms
got user at 500 ms
start posts at 500 ms
got posts at 1000 ms