フロントエンド大集合！うひょさん＆あっきーさんと語る！Next.jsお悩み相談室

これは以前の記事の復習ですが、React Server Componentsは多段階計算として捉えられるというお話をしました。この考えは現在でも有効だと思っています。具体的には、React Server Componentsが入ったアプリというのは、2段階で描画されます。まず1段階目でサーバーコンポーネントがレンダリングされ、その次の段階として、クライアントコンポーネントがレンダリングされる、という流れです。

各コンポーネントの特性と活用術

サーバーコンポーネントとクライアントコンポーネントは特性が異なります。サーバーコンポーネントはいくつか特徴があり、一つはサーバー側でキャッシュが利くことです。サーバー側でデータを使ってコンポーネントをレンダリングする際、サーバー側のキャッシュを活用できます。あと、サーバーでコンポーネントのレンダリングを行うので、クライアントの計算が削減できます。これによりいわゆる転送量、JavaScriptのソースコードをどれだけフロントエンドに送るかというところも削減できるケースも多々あります。 ただデメリットもあります。例えばサーバーコンポーネントを再レンダリングする場合、結果の取得にネットワークを経由する必要が出てきます。その反面、クライアントコンポーネントの特性として、サーバーを介さなくてもフロントエンドの計算だけでコンポーネントの再レンダリングが可能になります。その裏返しとして再レンダリングだけでなく最初のページ表示にもJavaScriptをクライアント側で実行する必要があります。 元々いわゆるSSRで初期HTMLが用意されていても、ハイドレーションを実行するためにクライアント側でちゃんとJavaScriptを実行する必要があります。これは従来のReactの考え方と同じですが、新しくサーバーコンポーネントが登場したことによって、クライアントコンポーネントの相対的なデメリットになったと思います。

各コンポーネントの使い分け：現代のWeb開発における「アイランドアーキテクチャ」

どう使い分けをするのかというのはやっぱり自然な疑問ですよね。私が紹介する考えというのは、土台となる部分にサーバーコンポーネントを使うということ、そしてその上でインタラクションが必要な部分にクライアントコンポーネントを使うということ、これが基本的に有効だと思っています。いわゆるアイランドアーキテクチャと同じ考え方で、今回あっきーさんと共演ということで彼の記事から引用をさせていただきました。React Server Componentsも実はこれに近い考え方なんです。なぜならこのReact Server Componentsでは、従来ステートとして保持していたサーバーからのデータが、インタラクションに直接関係しないという場合もあるんですね。なのでクライアント側のステートではなく、サーバーコンポーネントにデータ取得を担ってもらうことで、クライアントのステートを削減できるという考えです。