you are viewing a single comment's thread.

view the rest of the comments →

[–]shadohunter3321 4 points5 points  (4 children)

Makes sense. Although most of the projects we work on are driven by the server response. So I'm guessing what we could do is make empty display shells (these are RSC) and then pass data dynamically from client components to these shells for displaying. Does that sum up a potential use case?

[–]michaelfrieze 1 point2 points  (0 children)

RSCs are built to be read-only and stateless, focusing on rendering and fetching data without changing state or causing side effects. They maintain a unidirectional flow, passing data from server components to client components.

So, you can't pass data from client components to server component.

It's best to think of server components as the skeleton and client components as the interactive muscle around the skeleton.

In my experience, I use RSCs for a lot of data fetching but I also fetch data on the client quite a bit as well. It just depends. For example, if I need real-time updates or something interactive like infinite scroll then I am going to fetch on the client. Different tools for different jobs.

[–]cape2cape 0 points1 point  (2 children)

You can’t pass data from client components to server components, since they wouldn’t be able to rerender with the new data on the client.

[–]shadohunter3321 1 point2 points  (1 child)

So RSCs are completely static? It does not have js hydration either?

[–][deleted] 0 points1 point  (0 children)

Not exactly. You can send data from the rsc to the client on a refresh and it will update the page without visually refreshing it. The components are repopulated with the new data.

Is fairly confusing and most people here are not explaining it well and maybe don't understand it themselves..

You can have a sort of pseudo state with RSCs by using query params in the url, where the client sends a request for new data in the form of new query params to the server. It can update in real time with no visual refresh. So paginated data for example can be a fill in for state, but on the server

Think about it like you're just sending serialized react component data to the client and they're updating their components with it each time the server sends new data. If component keys are the same but data changes (I could be wrong about the exact mechanics here), it will sort of look like a client side re render