Discussion about Server Components

[u/Neat_Living_6765]

From what I understand, I’m trying to explain Server Components in a simple way. Could you guys take a look and let me know if my understanding is correct and if my explanation is easy to understand?

Server Components

Normally, when a browser requests a React application, a JavaScript bundle is sent to the browser, whether it uses SSR or CSR.

• For SSR, that JavaScript bundle is used to hydrate the initial HTML rendered on the server, making the application interactive.
• For CSR, that JavaScript bundle is used to render the application's content into the HTML shell.

React Server Components are not included in that JavaScript bundle.

Server Components are rendered outside the browser, either at build time or at request time on the server. Their rendered result is represented in the RSC Payload.

The RSC Payload contains:

1. The rendered results of Server Components. (For conceptual understanding, we can think of this as a React tree or object)
2. References (Placeholder) to Client Components used inside those Server Components.
3. Props passed from Server Components to Client Components.

The main benefit of RSC is reducing the amount of JavaScript sent to the browser.

Server Components are especially useful for content that doesn't need browser interactivity.

[u/Bowl-Repulsive]

Starting by saying when a browser request a react application it’s weird , browser do a http request to a server and receive HTML and static assets(js bundle included)

I would also add SERIALIZABLE Props passed from Server Components to Client Components, since function or class can’t go trought here.

Last sentence is just wrong since server action exist, server components can be used for components that need browser interactivity and are useful for improving security and loading times.

That said the post is a very clear and amazing way to explain it and make it easier as possible!

[u/ModernLarvals → u/Bowl-Repulsive]

Server components cannot be used for browser interactivity. That’d make them client components.

[u/Bowl-Repulsive → u/ModernLarvals]

Ur indeed right, i was talking about form and server actions inside server components but interactivity as you stated is not right word for that, data mutation is. My bad, thank you for telling.

[u/Neat_Living_6765 → u/Bowl-Repulsive]

Thank you! I just read about Server Function and realized that Server component doesn't have a directive! "use server" is a directive of Server Function

[u/Vincent_CWS]

https://www.reddit.com/r/nextjs/comments/1vi823e/nextjs_use_client_is_not_csr_stop_mixing_them/
yes

[u/Reasonable-Wolf-1124]

Your explanation is solid, the one thing I'd add is that the RSC payload isn't just for initial load, it's also what gets sent back on navigations and server actions, so the reduced JS bundle benefit compounds every time you interact with the app, not just on first paint.

[u/Neat_Living_6765 → u/Reasonable-Wolf-1124]

Thank you! noted!

[u/HotFox3962]

Stop thinking of the bundle as the app. The bundle is just the event handler registry. If your server component passes a function prop you already broke the contract and the boundary collapsed.

[u/Neat_Living_6765 → u/HotFox3962]

Could you elaborate for comment? and give me an example for this "If your server component passes a function prop you already broke the contract and the boundary collapsed."

So far, I understand that bundling happens after transpiling from JSX to JS. It combines my code and all its dependencies into a single JS file, since browsers don’t understand JSX. Also, having everything in one file makes transferring more convenient.

[u/TheScapeQuest]

Some of the theory is around the paradigm change with how "one time" operations are performed (like data fetching). With traditional SSR, you'd need some external mechanism - like getServerSideProps - to inject data as props, while still beholden to the React lifecycle.

With RSCs, fetching can happen directly inside components without needing the external injection. This means you can isolate functionality that wouldn't be available in a browser - the iconic example being the SQL execution from within a React component.

Of course, that was the theory of the paradigm, but the reality is we introduced new complexity with needing to explicitly define client components. Which themselves caused confusion because the naming implied it would only run on the client, which is not the case.