How to avoid fetch on render in React data fetching

TL;DR

Fetch on render is discouraged and data loading should be managed before rendering. The video explains why rendering then fetching causes waterfalls and slower user experiences, compares render as you fetch to fetch on render, and notes that patterns like data loading in routes can help start loading data earlier. It also acknowledges community drama and highlights that fetch on render is a bad practice for most apps.

Transcript

I'm going to be honest with y'all this video is a bit of a mess it started because one of my favorite authors wrote a great blog post about collocation of data in your components and how react data fetching model has gotten both Messier and better I ended up getting triggered pretty hard throughout and the results was a diagram a very good diagram ... Read More

Key Insights

• Fetch on render is identified as a problematic pattern because data fetching starts only after the component renders, delaying data availability.
• Waterfalls occur when each data fetch triggers another render before the previous data has loaded, increasing latency and network round trips.
• The video contrasts fetch on render with render as you fetch, noting that the latter can improve fallback timing but may complicate data loading.
• React 19 changes initially altered suspense behavior on the client, leading to community pushback and a later reversal.
• The author emphasizes that not all libraries rely on suspense in the same way, so changes affect different users differently.
• Remedies include moving data loading responsibilities out of components, such as loaders in routes, to start fetching data earlier.
• The discussion includes real world examples where a back end does not provide all needed data in one response, highlighting frontend back end coordination challenges.
• The takeaway is that practical data loading often requires collaboration between front end and back end teams to avoid over fetching and under fetching.
• More videos from this channel:
  • Why Do AI Costs Keep Rising Across Models?
  • What is GPT6.1 Soul and why it costs less
  • How to build fast lightweight websites with HTML
• More from this channel: Theo - t3․gg

Questions & Answers

Q: How can you avoid fetch on render in a React component

To avoid fetch on render you should move data loading responsibilities away from the component itself, so data fetching can start before the component mounts. This means using patterns like route level data loaders or parent components that initiate data fetches and pass data down as props. The goal is to prevent waterfalls and ensure data is ready when the component renders.

Q: What is the difference between render on fetch and fetch on render

Render on fetch means initiating data loading as soon as the component renders, which can delay rendering while data is fetched and result in multiple round trips. Fetch on render considers starting data loading outside the initial render, allowing the UI to show a loading state and reducing total wait time by prefetching data or loading in parallel where possible.

Q: Why did the React community push back on the suspense change

Community pushback arose because the change affected libraries depending on the original behavior, and many developers relied on different suspense usage patterns. The concerns centered on performance, user experience, and the potential for waterfalls, prompting a revert and a call for better alternatives that balance flexibility with predictable loading behavior.

Q: What pattern helps start data loading before components render

A pattern that helps is moving data loaders out of the components and into routes or higher level components so data fetching can start earlier. This approach reduces render delays, prevents waterfalls, and lets components render with data available, improving perceived performance and user experience.

Q: What is a practical challenge when back ends do not return complete data

A common challenge is that the backend may return only identifying data, requiring additional API calls to fetch full details. This forces the frontend to orchestrate multiple requests, which can slow rendering and complicate data flow, highlighting the need for better coordination between frontend and backend teams.

Q: How does the video describe the impact of suspense on client side

The video notes that suspense behavior on the client was experimental and that big libraries relied on it differently. Changes in suspense can affect how data is loaded and rendered, influencing both performance and developer experience, which is why the community engaged in discussions and reviews of its practical implications.

Q: What role do libraries like react query and trpc play in data fetching

Libraries such as react query and trpc depend on suspension patterns for some data fetching flows, but usage varies among users. The discussion highlights that while these libraries can leverage suspense features, not all users actively utilize those specific suspense queries, so impact varies across the ecosystem.

Q: What is the suggested direction for improving data loading in React apps

The suggested direction is to de-emphasize fetch on render and promote data loading strategies that start earlier, such as route level loaders or parent component data fetching. This helps reduce waterfalls, speeds up initial render, and aligns backend responses with frontend data needs for smoother user experiences.

Summary & Key Takeaways

• The video clarifies the difference between render on fetch and fetch on render, arguing that the latter leads to waterfall loading and slower initial render when data is loaded after the component renders.

• It discusses the controversy around React 19 changes, the community response, and the decision to revert a change in favor of better data loading patterns.

• It suggests patterns like moving data loaders out of React into routes to start data loading earlier and reduce loading delays.