You can continue to use state management libraries that take advantage of React hooks or other client-side logic inside of client components. Alternatively, you can move state management entirely to the server. That could be state in your database, URL state, or something else.
Hey Lee! Thanks so much for responding.
What's not clear to me is where do the providers go (ReduxProvider, ReactQueryProvider etc)?
Can they be instantiated up tree in a server component somewhere? And if that's the case, what data do they hold when on the server and what happens a client component tries to interact with the provider?
Or should I render as much as possible via RSC and put the providers in the first client component in the tree?
I've been trying to keep tabs on the GitHub issues and Discord that discuss this, but I have to admit, it's a bit over my head. The best resource I've found so far to understand how libraries are adapting is from Apollo's RFC here: https://github.com/apollographql/apollo-client-nextjs/blob/p...
Sorry for the late reply, but we have docs here! https://nextjs.org/docs/getting-started/react-essentials#con...
However, with adopting the App Router there is a big looming question - what happens with frontend state/query management libraries like react-query/trpc?
So far, I’ve seen unergonomic solutions that require the developer to manually hydrate the frontend. Hopefully, over the next few months we discover a solution that “just works”, so we can widely adopt RSC.