last night, I was skimming TanStack Query docs and went down a rabbit hole on its server-side usage with Next.js. What I found is a total gamechanger for performance. @tan_stack 🤯
>it's a pattern that combines server-side prefetching with client-side hydration to practically eliminate initial page load spinners. When you pair it with Server Actions for mutations, your app feels insanely fast.
here's how it works, a Thread 🧵
(1/n) Comparison:
>the old way (Client-Side Fetching):
You go to a restaurant and sit down. Only then do you call the waiter, place your order, and wait for the kitchen to cook and bring you your food. That "waiting for your food" part is the loading spinner your user sees.
>the new way (This Pattern):
You pre-order your meal online. When you arrive at the restaurant, the food is already on your table, hot and ready to eat. No waiting! This is what we're giving our user an instant experience.
will elaborate below.
(2/n) why old way is slow and bad? let's see
>in the traditional client-side fetching model, the data fetching process creates a noticeable delay for the user.
>when a user requests a page, the server initially sends a minimal HTML structure and the required JavaScript. The browser renders this data-less page, forcing the user to see a loading state.
>only after this initial page is loaded does the client-side code execute.
A useEffect hook then triggers a second network request to an API endpoint to fetch the necessary data. The server processes this request and sends the data back. Once the browser receives the data, the component updates its state, triggering a re-render to finally display the content. This multi-step process, where data fetching starts only after the page is already on the client, is the direct cause of the perceived delay and loading indicators.