devdumpling
commented
2 weeks ago I stand corrected, BatchHTTPLink does work. There was a bug in my setup where I was registering n RSC clients per request instead of 1 client to 1 request.
After fixing that, batch does seem to batch them together as expected. The downside is now that they're batched I don't have as much granularity in terms of what order I suspend data into my mostly content-driven page, but it's helpful to know this works. I will play around with fragment composition too and get back to you.
phryneas
Has the guidance for how to compose queries / requests on a page evolved at all in the time this package has matured?
When the Next app router came out there was a big push to let each component be in charge of its own data, with assurances that the automatic deduping and caching of requests would ensure that it didn't matter if you fired off redundant queries.
This makes perfect sense to me in a world where your backend is all REST endpoints or hitting some kind of DB directly.
In a graph though it feels a little harder to pull off without making multiple network requests that before could have been rolled into a single graph request at the top of the page and fed down to components.
I'm trying to understand how we can achieve high composability of components that need data without firing off multiple network requests. In client components with AC we can use fragments and fire off a query at the page level that stitches all of them together, and that works. Is there an equivalent in RSCs?
As an alternative I tried using a Batch HTTP Link in my RSC client but that didn't seem to work.