Below, we’ll walk you through why RSCs needed to be created, what they do best, and when to use them. We'll also touch on how Next.js eases and enhances the RSC implementation details through the App Router.

• RSCがなぜ必要なのか
• 何が得意なのか
• いつ使うのか
• AppRouterのサポート

について

What did server-side rendering and React Suspense solve?

To better understand the need for RSCs, it's helpful first to grasp the need for server-side rendering (SSR) and Suspense.

これはそうだなと思う。RSCとSSRの概念の区別がつけば6割理解できてそう。

With SSR alone, the user gets HTML more quickly, but must wait on an "all-or-nothing" waterfall before being able to interact with JavaScript:

• All data must be fetched from the server before any of it can be shown.
• All JavaScript must download from the server before the client can be hydrated with it.
• All hydration has to complete on the client before anything can be interacted with.

これは2021のConfのやつだ。めちゃわかりやすいよね。"all-or-nothing"をいかに解決するか？っていう観点で整理するとAppRouterもわかりやすい。

This vastly improves the situation, but still leaves a few remaining issues:

• Data for the entire page must be fetched from the server before any components can be shown. The only way around this is to fetch data client-side in a useEffect() hook, which has a longer roundtrip than server-side fetches and happens only after the component is rendered and hydrated.
• All page JavaScript is eventually downloaded, even if it's streamed to the browser asynchronously. As app complexity increases, so does the amount of code the user downloads.
• Despite optimizing hydration, users still cannot interact with components until the client-side JavaScript is downloaded and implemented for that component.
• The majority of JavaScript compute weight still ends up on the client, which could be running on any variety of devices. Why not move it to the more powerful, predictable server?

たぶん最も重要なポイントだ。SSRが抱える問題点。

• getServerSidePropsみたいなことすると、ページ全体を待つ必要がある。コンポーネント単位で待とうと思うとuseEffect内でのfetchをする必要があるが、これはクライアントにJSが届いてからようやく発生する。遅い。
• 結局クライアントですべてのJSを読み込む必要がある。サーバーに預けたい。
• 必要なJSを読み込まないとinteractできない

What do React Server Components do?

RSCs individually fetch data and render entirely on the server, and the resulting HTML is streamed into the client-side React component tree, interleaving with other Server and Client Components as necessary.

合ってはいるんだろうけど早く公式ドキュメントほしいな。

Put another way, the server, far more powerful and physically closer to your data sources, deals with compute-intensive rendering and ships to the client just the interactive pieces of code.

やりたいことはこの1文に大体詰まっている気がする。

RSCs: Performance and bundle size

However, RSCs resolve all dependencies on the server, closer to the sources of your app's data. They also render out code only on the server, which is much faster at this task than client machines (such as mobile phones). Then, React sends only these processed results plus Client Components to the browser.

逆にSSRではなんでこれができなかったの？っていう点が重要で、そこを理解するためには「Hooksは書けない」という制約を理解する必要がある、よね？

RSCs: Interleaving and Suspense integration

RSCs are fully interleaved with client-side code, meaning that Client Components and Server Components can render in the same React tree.

だし、RSCはもはやコンポーネントの形を保ってなくて純粋にHTMLっぽいものとして扱われるんじゃないだろうか？要調査

It's important to note that Client Components are still SSR'ed on initial load. The RSC model does not replace SSR or Suspense, but rather it works alongside them to provide all parts of your application to your users as they need them.

これは素のReactでもそうなのか？Next.js（やその他のフレームワーク）の仕事ではないのか？

RSCs: Limitations

All code written for Server Components must be serializable,

Also, RSCs do not support continuous updates, such as through WebSockets. In these cases, a client-side fetching or polling approach would be necessary.

How to use React Server Components

The beauty of RSCs is that you don’t really need to know fully how they work to take advantage of them.

そうか...、うーん、この1文はReactっぽくない気がするけど。

Balancing Server and Client Components

The most important thing is that you continue to test your applications in non-standard environments: emulate slower computers, slower phones, and slower wifi, and you may be surprised to see how much better your app works with the right combination of components.

ああそうだった。こういうテストを習慣づけないと。

Improved data fetching with Next.js

Additionally, you no longer need Next.js-specific, page-level methods like getServerSideProps() and getStaticProps(), which didn't offer granular enough control for individual components and tended to over-fetch data. (When the user navigated to the page, all data was fetched, regardless of what components they actually interacted with.)

重要。all-or-nothingからの卒業。

Server Actions: React’s first steps into mutability

Within the context of RSCs, Server Actions are functions that you define in an RSC on the server side that you can then pass across the server/client boundary.

すごいよね、すごい

Specifically, Server Actions are designed to handle tasks like database updates or form submissions. For example, they can progressively enhance your forms, which means that even if JavaScript hasn’t loaded yet, the user can still interact with the form, and Server Actions will handle the submission and processing of the form data.

Remixはどうやって解決してたんだっけ。なんかうまいことやってたような。

Let Next.js do the heavy lifting

While you focus on building your product, Next.js uses strategic streaming and smart caching to make sure your application rendering stays non-blocking and serves dynamic data at top speeds.

実際12までよりもぐっと役割意識がはっきりしたような気がする。

Where do you go from here?

興味深い実例がリンクされている。
https://www.mux.com/blog/what-are-react-server-components
https://dagster.io/blog/dbt-docs-on-react
https://formidable.dev/blog/2023/powering-our-website-s-evolution-next-js-app-router-and-sanity-cms-in-action/