Simple Concept

• Client Component : UI = f(state)
• Server Component: UI = f(data)
• Combined: UI = f(data)(state) but not UI = f(state, data)
• The UI is updated using Currying with f(data)(state), while f(state,data) is a regular function call. This means that f(data) occurs on the server, but f(state) occurs on the client. Please keep in mind that there are some differences between f(data)(state) and f(state, data).

Long story Short version

tldr:
Before RSC coming, React was always treated as a SPA library/framework(ecosystem/architecture) because SSR for React was invented by Vercel, the author of Next.js.
RSC is an additional layer in traditional React for client components, and it's the first time React has introduced server-side matter.

Before RSC, you can consider that React will be packaged as a JS bundle and sent to the browser for download. At this point, it is similar to downloading a mobile application from an app store.
After downloading the bundle in the browser, all JS programs are installed in browser and any subsequent fetch or navigation will be done on the client side. For meta frameworks like Next.js and Remix, they won't include all of your ReactJS program into one JS bundle; instead, it will be divided by route/segment.

So SSR generates HTML on the server-side and sends the corresponding JS bundles for hydration in the browser to add interaction. This is different from RSC, because SSR naturally requires hydration in the browser even if it's server-side rendered HTML. The HTML generated in server is the real DOM, but the virtual DOM has not been generated yet. Therefore, in the browser, the component needs to run one more time to generate the virtual DOM and fiber tree. Otherwise, React will lose state(hooks) for the client component and reconcile will not be able work. This is why SSR runs twice - once on the server and once on the client.

After the introduction of RSC, a new data format called RSC payload will be used to represent components in React. There will be no browser API or hook involved; instead, a binary or JSON-like payload will be utilized within the browser by reactjs. The reason for not using HTML to represent RSC is due to its lack of flexibility in reusing and placing components correctly when React needs to re-reconcile them in rerendering phase.

---

---

History

From SPA (Single Page Application) to SSR (Server-Side Rendering), and now RSC (React Server Component), ReactJS has evolved over the past 10 years.

I remember the first time I used ReactJS when it was still using class components. Now, we have the option to define components using functions with hooks.

SPA is not good for user experience or SEO.
SSR does not effectively reduce the JS bundle size to improve performance.
RSC was introduced to solve this problem. Although it is not free, the JS bundle becomes an RSC payload, making it worth learning and using.

React Server Component is a new concept. They add a new layer to React client components,
It's similar to server-side rendering where the HTML is generated on the server, but RSC generates React-like JSON format.

AS Dan explained.
The component's location of import determines whether it becomes a server or client component.

RSCs do not require hydration, meaning the JS bundle is smaller than when using SSR (server-side rendering).

On the server(here is using NextJS as example), RSC generates a binary payload in React JSON format and send it to the browser. The browser then uses this with the hydrated client component to render the UI.

It is not meant to be used as a replacement for SSRs, but rather as a complement to them.

Some thoughts

Here is my summary:

1. The first layer is the server component and the client component
   1. The client component is traditional reactJS component that can be rendered either on the server side (SSR) or on the client side (CSR). With SSR, both HTML and JS bundles are generated on the server and sent to the client for hydration. On the other hand, with CSR, only the JS bundle and Shellnut HTML are sent to the client for rendering.
   2. The server component is officially released on reactjs18 and nextjs13, so all the component before nextjs13 and reactjs18 is client component. server component is a non-interactive component compared to client component, it can use server API or access server system.
      1. In the Server Environment
         1. React renders Server Components into a special data format called the React Server Component Payload (RSC Payload).
         2. Next.js uses the RSC Payload and Client Component JavaScript instructions to render HTML on the server.
      2. In the Client Enviroment(browser)
         1. The HTML is used to immediately show a fast non-interactive initial preview of the route.
         2. The React Server Components Payload is used to reconcile the Client and Server Component trees, and update the DOM.
         3. The JavaScript instructions are used to hydrate Client Components and make their UI interactive.
      3. The RSC Payload is a compact binary representation of the rendered React Server Components tree. It's used by React on the client to update the browser's DOM. The RSC Payload contains:
         1. The rendered result of Server Components
         2. Placeholders for where Client Components should be rendered and references to their JavaScript files
         3. Any props passed from a Server Component to a Client Component
      4. On subsequent navigations, Client Components are rendered entirely on the client, without the server-rendered HTML. This means the Client Component JavaScript bundle is downloaded and parsed. Once the bundle is ready, React will use the RSC Payload to reconcile the Client and Server Component trees, and update the DOM.
      5. Server component is rendered on the server side and sends the JSON notation(using streaming which means the component is async to send) used to render HTML instead of sending the whole HTML to the client (except for the initial load, it is sending the HTML in Nextjs)
         1. ReactJS will generate the RSC payload for RSC.
         2. NextJS will use generated RSC payload with client component JS instructions to render HTML on the server for the initial load. which means, client component and server component both are used in SSRd when user refresh the browser or first time visit the website.
         3. After the initial load, the JS bundle(most part, like layout, hook) has been downloaded in the user browser, so the subsequent request/navigation, RSC payload will generate in server too and send to client to rendering the page.
         4. At this moment, the existing JS bundle may lack of some elements for ongoing client component, so server will send the remind JS bundle to client for reconcile react tree and update the DOM.
   3. you can not import server components into the client components as this approach would require an additional server round trip.
      1. but you can composite it in another server component
      2. 
      3. also you can use Passing Server Components to Client Components as Props
      4. Instead, when designing Client Components you can use React props to mark "holes" for Server Components.
      5. The Server Component will be rendered on the server, and when the Client Component is rendered on the client, the "hole" will be filled in with the rendered result of the Server Component.
      6. A common pattern is to use the React children prop to create the "hole". We can refactor to accept a generic children prop and move the import and explicit nesting of up to a parent component.
      7. 
      8. 
2. The second layer is CSR and SSR
   1. As mentioned above, CSR sends the JS bundle to the client and ensures that rendering occurs on the client side.
   2. SSRd is pre-rendered at the request or build time and caches their HTML and JSON on the server, which is then sent to the client for hydration by ReactJS.
   3. However, the SSRd or CSRd will have a large amount of JS bundle for hydration. Slow performance of the network boundaries.
   4. the difference between RSC and SSR
      1. The RSC is a new thing that is added to the existing react tree as a new layer like the below pic
      2. By utilizing RSC, we can prevent the need to send the entire JS bundle to the client's browser. This is because RSC's library is only used on the server-side. As a result, this leads to a smaller JS bundle size.
         In contrast, for SSR, HTML is rendered either during build time or request time (similar to RSC). However, in order for hydration to occur, all of the JS bundles must be sent to the browser.
         Since RSC does not have interactive functionality, its JS bundle size remains smaller than that of SSR.
      3. The client component can also be SSR, just like before because the client component has interactive functionality, hydration is needed, the JS bundle will be bigger.
      4. The RSC operatesasynchronouslyand usesstreamingto send progressively updated results to the client, resulting in faster loading speeds.
      5. reduce the waterfall requests
      6. 
         React Server typically runs either at the build time (default), or on an actual server. React Client typically runs in both environments (in the browser it manages the DOM, in other environments it generates initial HTML).
      7. For the initial load, the RSC will provide the react elements along with the JS bundle, but client component can also be SSRd, so the HTML will be generated and sent from server in nextJS for initial load. Subsequently, when navigating to other pages or interacting with the website, a React-style JSON response will be sent to stream to the browser for rendering of the UI.
      8. tl:dr -
         1. No, they’re complementary. SSR is primarily a technique to quickly display a non-interactive version of client components. You still need to pay the cost of downloading, parsing, and executing those Client Components after the initial HTML is loaded.
         2. You can combine Server Components and SSR, where Server Components render first, with Client Components rendering into HTML for fast non-interactive display while they are hydrated. When combined in this way you still get fast startup, but you also dramatically reduce the amount of JS that needs to be downloaded on the client.
3. The third layer is Static and Dynamic rendering
   1. By default, Next.js 13 uses static rendering, which generates all components ahead of time during the build process.
      1. With Static Rendering, both Server and Client Components can be prerendered on the server at build time.
      2. The result of the work is cached and reused on subsequent requests. The cached result can also be revalidated.
      3. This is equivalent to Static Site Generation (SSG) and Incremental Static Regeneration (ISR) in the Pages Router.
   2. the dynamic rendering also renders the page in the server but will be rendered every single request
      1. With Dynamic Rendering, both Server and Client Components are rendered on the server at request time. The result of the work is not cached.
      2. This is equivalent to Server-Side Rendering (getServerSideProps()) in the Pages Router.
   3. we use two dimensions to identify whether the component is using static or dynamic rendering
      1. 
      2. what does the cached or non-cached mean in the data fetching?
         1. The "revalidate" and "no-store" flags determine whether to use or not use the cache.
         2. If you are using the "revalidate" or "no-store" options, it means that data fetching is dynamic.
      3. how about the dynamic functions?
         1. Dynamic functions rely on information that can only be known at request time such as a user's cookies, current requests headers, or the URL's search params. In Next.
         2. Using cookies() or headers() in a Server Component will opt the whole route into dynamic rendering at the request time.
         3. Using useSearchParams() in Client Components will skip static rendering and instead render all Client Components up to the nearest parent Suspense boundary on the client.
         4. Using the searchParams Pages prop will opt the page into dynamic rendering at the requested time.
4. one more thing, the Rendering Environments (The principle of three-dimensional rendering.)
   1. There are two environments where your application code can be rendered: the client and the server.
      1. client and server, one rendering in the client-like browser, one rendering in the server
      2. Server can refer to computers in regions where your application is deployed to, the Edge Network where your application code is distributed, or Content Delivery Networks (CDNs) where the result of the rendering work can be cached.
   2. Before React 18, the primary way to render your application using React was entirely on the client.
      1. However, this led to additional JavaScript needed on the client to make the initial HTML interactive.
      2. with Server and Client Components, React can render on the client and the server meaning you can choose the rendering environment at the component level.
   3. for the Page route system, Next.js provided an easier way to break down your application into pages and prerender on the server by generating HTML and sending it to the client to be hydrated by React.
   4. with Server and Client Components, React can render on the client and the server meaning you can choose the rendering environment at the component level.

The three-dimensional rendering involves different layers that perform distinct tasks. However, understanding the server component can be challenging for ReactJS developers since it is a new concept. Previously, all components in React were client-side and could be rendered on either the client or server-side using hydration.

Page route and App route:

Reference

1. The Two Reacts — overreacted
2. RSC From Scratch. Part 1: Server Components
3. Making Sense of React Server Components
4. Why React Server Components Are Breaking Builds to Win Tomorrow
5. React Server Components: the Good, the Bad, and the Ugly