Adam Luikart

I'm *very* thankful that React rolled back the v19 suspense gate and were willing to work with us. I think the future is as bright as ever. Now, this is where I want to go next: I'm increasingly concerned how much React is pushing render-as-you-fetch (hoisting+preloading) as the blessed (and last week, almost required 😜 too soon?) approach for client side data fetching, despite the current state of ecosystem. Regardless of the library you use to fetch client-side data, if you're not using a framework's SSR-level route loader or async paradigm, your solution probably resembles some kind of hook (like useQuery, or heaven forbid, one that you rolled on your own). I'm happy about the concern we all have for perf, UX, parallelism, etc, but not super happy that some of use are so quick to give up the amazing DX that is data colocation. AFAIK, Relay is one of few libraries that can really handle hoisting data requirements out of components automatically (not without a lot of buy-in and convention) and get you the best of both worlds. It's naturally that RSC is the spiritual evolution of this pattern. You could argue that a router with a loader lifecycle solves a lot of this, but (1) this assumes that your data usage-site is close to your route boundary and if it's not (2) you likely had to either move that data out of a deeper component that uses it and into the loader that then passes it back via prop 😮‍💨. Or.. duplicate your work by doing a split preload/use-later approach, which is the most monotonous feeling thing in the world and prone to error. Colocation on the other hand feels natural for projects that require this level of data dynamism in components (think dashboard widgets or productivity app). And for the most part, this works amazing.. unless you need SSR. And that's where I imagine React has likely been thinking server-components would fill in nicely. As always, SSR is the crux of it all and Relay was on to something. Regardless, If you need both colocation and SSR, you have to jump through hoops to get there. Annoying ones. Even with those annoyances though, it's hard for me to imagine many of these highly dynamic apps moving to an RSC future (unless SEO/SSR is in the bread and butter of their product, e.g. if you're a social network or e-commerce thang, it makes perfect sense). My point is that RSCs are not the only answer to colocated data fetching and honestly still require some kind of hoisting convention if you want to avoid server-side waterfalls. For starters? RSCs require architecture and opinion buy-in beyond `npm install react`. So when I see render-as-you-fetch, what I really see is a pretty hefty checklist: - Data Hoister (Compiler, router convention, etc) - Cache Coordinator (QueryClient, etc) -Consumer (useQuery, use, etc) And a whole much of hairy code to make sure that SSR works (streaming, hydration, etc) Yes, it's can be more performant to some KPIs and if you need those or SSR, you'll have to do it anyway, BUT it would be a mistake to think *everyone* is in that bucket. I would really like to see more attention going into retaining the awesome DX of being able to colocate data requirements with usage sites without forcing more cognitive load around prefetching patterns. I don't know what those solutions are yet. I have ideas. But even if we as an ecosystem were to go down that road, it would be 1000 times better if it was a problem React itself would consider as first-class instead of some cursed pattern that needs to be squashed or discouraged. This is why @Tan_Stack Query is so awesome IMO. Yes, there's some extra preloading to do if you need SSR, and for RSCs and frameworks, we're already hard at work on some pretty cool stuff (despite missing React primitives) to make it just work with RSCs. TanStack Start/Router will be no different. Reducing cognitive load is our goal and trying to remember if you preloaded or kicked off a fetch in a loader is high on my list of mental tasks to destroy. Please, don't kill colocation.