RSC

React 20 Server Componentsのベストプラクティス: RSC導入で変わるデータフェッチの常識と、クライアントコンポーネントとの使い分け はじめに 「Reactのデータフェッチといえば、useEffectとuseStateを使って、クライアントサイドでAPIを叩くのが当たり前。」 もしあなたがまだそう考えているなら、この記事はあなたの常識を覆すことになるかもしれません。 Next.js 13のApp Routerと共に本格的に導入されたReact Server Components（RSC）は、Reactアプリケーションのアーキテクチャ、特にデータフェッチの方法を根本から変えようとしています。もはや、すべてのコンポーネントがブラウザ上で動くわけではありません。サーバーでレンダリングを完結させ、クライアントにはインタラクティブなUIの部品だけを送る、という新しい時代が到来したのです。 しかし、この大きなパラダイムシフトは、多くの開発者に新たな問いを突きつけています。 「Server ComponentとClient Componentは、具体的にどう使い分ければいいの？」 「"use client"はどこに書くのが正解？」 「useEffectでのデータフェッチは、もう時代遅れなの？」 「SWRやReact Query（TanStack Query）はもう不要になる？」 この記事では、そんな疑問を抱えるあなたのために、React Server Componentsの核心を解き明かし、次世代のReact開発におけるベストプラクティスを徹底的に解説します。この記事を読み終える頃には、あなたはRSCを自信を持って使いこなし、より高速で、より効率的なWebアプリケーションを構築するための確かな知識を手にしていることでしょう。 なぜRSCは登場したのか？ 従来のReact開発が抱えていた課題 React Server Componentsがなぜこれほど注目されているのかを理解するためには、まず従来のクライアントサイドレンダリング（CSR）やサーバーサイドレンダリング（SSR）が抱えていた課題を振り返る必要があります。 課題1: クライアントサイドでのデータフェッチの限界 SPA（Single Page Application）の普及以降、React開発の主流はクライアントサイドでのデータフェッチでした。しかし、このアプローチにはいくつかの構造的な問題が存在します。 ネットワークウォーターフォール問題 コンポーネントのレンダリングが完了してから、useEffect内でデータフェッチを開始するため、親コンポーネントのデータ取得が終わらないと子コンポーネントのデータ取得が始まらない、といった連鎖的な遅延（ウォーターフォール）が発生しがちでした。これにより、ページの表示完了までに時間がかかっていました。 1 2 3 4 5 6 7 8 9 10 11 12 // 典型的なウォーターフォール function ProfilePage() { const { user } = useUser(); // 1回目のAPIコール // userが取得できてから、次のコンポーネントがレンダリングされる return user ? <UserDetails userId={user.id} /> : <Spinner />; } function UserDetails({ userId }) { const { posts } = usePosts(userId); // 2回目のAPIコール // ... } バンドルサイズの肥大化 データフェッチのためのライブラリ（axios, SWRなど）、状態管理ロジック、データ整形ロジックなど、すべてがJavaScriptバンドルに含まれ、クライアントに送信されます。アプリケーションが複雑になるほどバンドルサイズは増大し、初期ロード時間（Initial Load Time）を悪化させる大きな要因となっていました。 ...