In this blog post I am going to touch on the core ideas behind the React Server Components architecture and why it exists. This is not a tutorial on how to practically use RSC but rather a general and newcomer-friendly explanation of the behind the scenes.
With RSC, React has now the primitives to identify and handle those cases: server components can be processed and serialized to a JSON-like format that is picked up in the browser and combined with client code (interactive components).
Think of the RSC architecture as a powerful flavor of a Virtual DOM engine which can discern between pre-computable code and client code and can then reconcilie them in the browser.
A compiler will split an application into "server" and client and React can then do the RSC serialization at build time or on the fly.
Therefore the S (Server) in RSC doesn't automatically imply Server Side Rendering: React instead serializes any component that doesn't include the
"use client" directive to a JSON-like format. This kind of component is called a Server component.
The serialized RSC payload can be then rendered at build time to static HTML, on the server upon request (SSR) or in the browser (CSR).
What Happens to Client Components?
In the browser React will use these references to mount the client component using the serialized information from the RSC payload.
The React Server Component architecture presents a cohesive programming model where the entire application is authored as a single React tree with mixed static and interactive bits.
If we think of components as declarative controllers that return a view, React now offers a seamless way to author and combine data-centric controllers (server) and presentational interactive ones (client) with no manual or imperative wiring needed.
This unlocks a very powerful programming model.