take this example and rewrite the server parts into tanstack server functions without breaking their encapsulation overreacted.io/impossible-c... then how do you ensure all of their data arrives in a single roundtrip? RSC does guarantee it by executing all server parts together - ThreadSky

danabra.mov • 33 days ago

take this example and rewrite the server parts into tanstack server functions without breaking their encapsulation https://overreacted.io/impossible-components/#final-code

then how do you ensure all of their data arrives in a single roundtrip? RSC does guarantee it by executing all server parts together

Comments

callin.cc•33 days ago

I feel like the dataloader pattern is way too unexplored outside of graphql and would work great in the client to avoid breaking encapsulation. Same goes in your server example which works for reading files, while more realistically you want to avoid N network calls to the db.

danabra.mov•33 days ago

yea on the server it’s awesome! i wouldn’t say it saves the day on the client, although it does help with batching

danabra.mov•33 days ago

i’ll write about that more explicitly though. good callout

sh03.dev•33 days ago

I'm not entirely sure what "without breaking their encapsulation" means but for that example I would use Tanstack Start + Query, have a route with a useSuspenseQuery to fetch posts and an ensureQueryData in the loader and that would load the posts in a single roundtrip since loaders are isomorphic.

sh03.dev•33 days ago

The mental model here is: just think about writing an SPA and then add ensureQueryData as an optimization to load everything in one go.

danabra.mov•33 days ago

how would you know which queries to call ensureQueryData? i think id need a more complete example just to see it. here i have an entire list of PostPreview, each of which loads some data of its own. you’d have to make at least one request to get the list of IDs — and then… thirty parallel requests?

danabra.mov•33 days ago

also consider that you’re already breaking encapsulation. you’re forcing the knowledge about PostPreview’s internal data dependencies onto some other layer that’s supposed to prewarm them (router? parent components?)

danabra.mov•33 days ago

now, i’m speaking in absolute terms (some prewarming can be good for RSC too on the server), but fundamentally the client just isn’t able to encapsulate data dependencies without client/server waterfalls.

sh03.dev•33 days ago

True but I don't think about it as another layer. Also most of the when I want this single roundtrip it's for a specific reason (e.g. SEO) so optimizing specific pages is an option.

Maybe you could enforce this with tests + useSuspenseQuery + a suspense boundary that throws an error or something.

danabra.mov•33 days ago

i mean, this works to some extent. but single roundtrip is important for navigations. you don’t want next page to stall. and you also don’t want it to be jumpy.

with relatively small codebase you can indeed do manual stuff to keep it under control. that’s not the same thing as it “just working”

sh03.dev•33 days ago

Sorry, I forgot about the part where each post fetches its own data. Yeah that wouldn't work well with loaders (although it's technically possible to implement it with the same performance with ensureQueryData).

sh03.dev•33 days ago

But then again I'm a "fetch at the top when possible" kind of guy so I wouldn't recommend that pattern anyway.

danabra.mov•33 days ago

we shape our tools, and in turn, our tools shape us :)

ryansolid.bsky.social•33 days ago

I think the reason this argument never carries is because people have been solving this problem since the beginning. GraphQL is a solve, hoisting is a solve. The only thing people don't intentionally do is make 30 parallel requests. And a trivial example can always avoid it.

ryansolid.bsky.social•33 days ago

The solution in all cases involves building up a larger data set in a single request on the server. Which becomes more specialized to the UI. So you do make server components in sense. Maybe made of JSON. But now you have to update 2 locations on any code change. It's not unlike MVVM vs Components.

ryansolid.bsky.social•33 days ago

I think the composition argument is fair. The part that is less obvious is how easy it is to have multiple trees on the page that can entwine. What if you don't need to update the whole page on every mutation. Its a lot easier to picture that in a decoupled model.

Comments

Posting Rules

Reply