Open questions

[KATT]

Just dumping some thoughts / half-baked ideas here

• With RSC - is there a point of tRPC? Is there a "lighter" approach that might be nice(r)? Maybe, but not for all
• With RSC - is there a point of react-query? yes, there's still client components
• Will there be a way to sync state and make sync the underlying state of the queries from RSC -> client & make isomorphic components?
  • Biggest question - unsure how state sync can work from a root "use client" Provider that renders on the server to the client that uses it.
• Will importing the full router on every RSC-request add any significant overhead?
• Will React Context providers be available on the server? If so, it be possible to do any "isomorphic" context providers? Will components be able to be isomorphic? This was a misconception. We'll do a root "use client" component & likely not sync state from actual RSC-components to client
  • If query state could be synced from server to client and context providers + components could be isomorphic, we could do stuff like using optimistic updates of a component that was initially rendered on the server.
• How to deal with caching?
• [..]

[alancunha26]

I guess until they find a way to deal with mutations, will be very hard to stop using stuff like react-query. Maybe we could use server components initial data in react query?

[eug-vs]

It looks like most of the querying can be covered by RSC & streaming. But I guess there are some cases when you want to query the actual JSON not for rendering HTML, but for some logic (e.g change the client component behavior based on a server response).

Will there be a way to sync state and make sync the underlying state of the queries from RSC -> client

If so, we probably only need react-query for mutations.

If there would be way for 2-way sync RSC <-> client (which I can't imagine) then yeah not sure if tRPC is needed, but we are far from it

[oscartbeaumont]

I have been looking into RSC and React Query and wanted to share an idea I have been hacking on. It's still a work in progress but I would be interested in your thoughts and if something like this is useful for tRPC.

I have built a useData hook which by my understanding can be called identically within an RCS (here) or client component (here).

Data fetched by using the hook in a RSC is also populated into the React Query cache on the frontend automatically.

The demo currently loads very slowly because:

• I am currently using await setTimeout(..., 1000) as a workaround for the lack of SuspenseList in stable React. I am going to investigate if there is a way to get what I need without SuspenseList.
• I am also using await setTimeout(..., 1000) to mock a network call.

The guts of the example are all in ./utils/someLibrary.tsx.

The repo is here and it is hosted on Vercel here.

[greendesertsnow]

I didn't check the totality of Next 13 and just watched a video or two about this library but..
Doesn't this setup have a little too much going on for client side data interaction?
I mean, now that components are server side, and caching and invalidating is simplified; if an app does not have too many dynamic data interactions, why bother with tRPC and React Query?
I would have a very hard time following this code example if I didn't have any idea about Next 12, with routes and pages and stuff.... too much boilerplate for a dozen of requests.

Also.. where does load RQ's loading and error states sit in with Next 13?

[KATT]

Moving this to trpc/trpc#3297 to not have two threads