Closed KATT closed 1 year ago
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?
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
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:
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
.await setTimeout(..., 1000)
to mock a network call.The guts of the example are all in ./utils/someLibrary.tsx
.
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 tRPC is awesome, I'm just wonder on how tRPC will work with Next 13 App Directory feature? would like know, anyone do some stuff with Next13 App Directory feature?
Moving this to https://github.com/trpc/trpc/issues/3297 to not have two threads
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 allWith RSC - is there a point of react-query?yes, there's still client components"use client"
Provider that renders on the server to the client that uses it.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