React Server Componentsへ5万行のコードを移行する前に知っておきたかったこと

• 著者が50,000行のコードをReact Server Components（RSCs）へ移行する中で経験し、学んだ教訓についての記事
• RSCsはクライアントではなくサーバーで実行されるReactコンポーネントで、サーバーサイドレンダリング（SSR）に対して2つの主要な利点を提供
  • 第一に、RSCsは開発者がコードの実行場所を定義できるようにし、バンドルサイズを縮小し、hydration中の作業を減らす
  • 第二に、サーバーコンポーネントはコンポーネント内で直接データを取得し、それをクライアントへストリーミングできるため、Reactにおけるデータ取得をより簡単かつ効率的にする
• しかし、RSCsの利用にはいくつかの制約がある。CSS-in-JSはサーバーコンポーネントでは動作せず、React Contextにはクライアントコンポーネントからしかアクセスできず、コードが実行される場所を管理する複雑さが課題になりうる
• 著者は、RSCsを段階的に採用するための3段階のアプローチを提案
  • アプリのルートに"use client"ディレクティブを追加する
  • レンダリングツリー内で、可能な限り低い位置へそのディレクティブを移動する
  • パフォーマンス上の問題が発生したときに高度なパターンを採用する
• この追加の複雑さにもかかわらず、著者は、より小さなバンドルサイズ、より高速な実行、高度なデータローディングパターンといったRSCsの利点は、チームにとって性能面のメリットが重要である場合、そのコストを上回りうると結論づけている

[GN⁺]

Hacker Newsの意見

• この記事は、50K行のコードをReact Server Components（RSCs）へ移行する議論を扱っています。
• 一部のユーザーは、サーバーサイドレンダリングの速度と手軽さに触れ、クライアントがすぐに閲覧できるHTMLを受け取れる点を指摘しました。
• RSCsの代わりに、Rails、Django、LaravelなどのフルスタックまたはクラシックなWebフレームワークを検討するほうが、より高速でスケーラブルな解決策になり得るという提案があります。
• 一部のユーザーは、現代のフレームワークの複雑さに懸念を示し、単純な作業にも広範なビルドおよびコンパイルのパイプラインが必要になることに言及しました。
• ユーザーたちはnext.jsとその新しいappディレクトリ構成に関する個人的な経験を共有し、処理がどこで行われているのか（サーバーまたはクライアント）を理解する難しさや、クライアント側での動作を前提とする既存のReactライブラリとの問題点を強調しました。
• 一部のユーザーは、新しいnext.jsのappディレクトリパラダイムにおけるバグや粗削りな部分を指摘し、動的ルートや並列ルートに関する問題を含めて挙げました。
• あるユーザーはPHPとJavaScriptの類似性に触れ、JavaScriptはより多くの略語と急な学習曲線を持ちながらも、似たようなサーバーサイド機能を提供する方向へ進化してきたと指摘しました。
• 一部のユーザーは、静的サイトジェネレーターやキャッシュ付きCMSのような、よりシンプルなツールで解決できる作業にReactを使う必要性に疑問を呈しました。
• サーバーがすべてをレンダリングし、CSSとJavaScriptがレンダリング後にページを強化していた時代へのノスタルジーがあります。
• 一部のユーザーは、Reactが現代的でより簡単かつ高速な代替手段に追いつくため、さらに複雑になっているという見方を示しました。
• ReactをバックエンドでHTMLをレンダリングするために使うことをめぐる議論があり、一部のユーザーはその必要性に疑問を呈し、別のユーザーは従来のサーバー返却方式よりも利点があると擁護しました。