[SebastianKra]

This looks nice for a single query, but, like basically all the previous discussion around this, he skips over the case where you might need to kickoff fetching of dependent data.

So in your loader, you would have to fetch the data, transform it, extract a key for the second query and then prefetch that.

...and in your component you would have to do the exact thing again, except you probably have to write the transformation logic twice, because hooks don't compose well with promises.

Of course you might say that dependent queries are a bad practice anyways, but in the real world this happens quite a lot.

To be clear, Suspense was always bad at this. To my knowledge, there was never a good way to combine SWR and lazy fetching with Suspense. You may or may not have been lucky, if your queries mapped well to the component tree.

I would like to see a solution from either React-Router or Tanstack-Query, but both of them prefer discussing the problem away.

[ddaalluu2]

Their solution is graphql, but I believe that the backend should have data for each component ready.

Example social network.

  /api/pagedata/FrontPage

returns a big ass query result, all posts with comments, comment count and reactions, all the data you would ever want in your front page.

  /api/pagedata/UserProfilePage

returns all the relevant data regarding the user's profile page.

Yes, if you change or extend a certain page, you will have to change the backend query. If you have 2 different teams for frontend and backend that's not straightforward, so there should be something where the frontend team writes the detailed expected json response and the backend team transforms that into queries. Or, let's be real, the queries get generated. One could even imagine a middleware that translates expected json to graphql queries.

Why not directly graphql? Because it's a major pain in the ass, because of relay. Graphql is Facebook. And instead of having the simple structure you can easily query, they added this stupid node relay structure which makes everything overly complicated.

I could imagine a Go backend or Rust where you have a comment with the expected JSON, and you type go generate and boom generated queries with search and pagination.

[SebastianKra]

I don't know who decided it was right to flag you into oblivion, but GraphQL is unrelated to this.

You don't always have full control over the backend. You may depend on another team, or maybe even access a public API. React was (and still is) good at that, but with suspense, it's as if they forgot that a Web-App may want to do more than just "take stuff from server and show".