Garden

最近の記事

Next.jsにおける正しい設計のコンポーネント種別

10 min read

Prompt

Next.jsでの、正しい設計をした場合でのあるコンポーネントの、サーバーコンポーネント率/クライアントコンポーネント率はどのような感じ？

  • page.tsx
  • ボタン
  • SNSの投稿などのDBから取得し表示するもの
  • ただの飾り
  • アニメーション付きの飾り
  • 処理をまとめたHook
  • (その他あれば)

Next.js（App Router）における「正しい設計」は、一言で言うと**「サーバーコンポーネント（RSC）を木の幹にし、クライアントコンポーネント（RCC）を葉にする」**という形になるよ！

キミが作っているチャットアプリ「AXON」や、専門学校でのプロジェクトにも直結する、非常にコンストラクティブな構成案を整理してみたよ。

🛠 コンポーネント別：RSCかRCCか？

結論から言うと、**「データ取得と静的表示はRSC、ユーザー操作とブラウザ依存はRCC」**という明確な棲み分けになるんだ。

コンポーネント種類なぜその選択をするのか？
page.tsxRSCApp Routerの起点。ここでDBからデータを取ってくるのが王道。
ボタンRCConClick などのイベントリスナーはRCCでしか動かないからね。
SNSの投稿 (DB取得)RSCNext.jsの真骨頂！ DBに直接アクセスし、HTMLとして出力。クライアントにJSを送らなくて済む。
ただの飾りRSC静的なHTML/CSSだけで完結するなら、JSは一切不要。
アニメーション付きの飾りRCCframer-motion や useEffect を使う場合、ブラウザのAPIが必要になる。
処理をまとめたHookRCC用Hooks（useState 等）はそもそもRCCの中でしか呼び出せない。

📐 理想的な「サーバー/クライアント率」の構成図

理想的な設計では、**「データの流れはサーバーから、インタラクションだけをクライアントに」**と考えるんだ。比率で言うと、コード量の80%以上がRSCに収まっているのが、パフォーマンス的には「美しい」とされるよ。

1. サーバーコンポーネント（RSC）の領域：約80%

  • 役割: データ取得（Fetch）、セキュリティ（APIキーの隠蔽）、SEO、巨大なライブラリの利用。

  • メリット: クライアントがダウンロードするJavaScriptの量を劇的に減らせる。キミが気にしていた「キャッシュヒット」も、サーバー側のデータキャッシュが効くから爆速になるよ！

2. クライアントコンポーネント（RCC）の領域：約20%

  • 役割: onClick、onChange、useState、useEffect、ブラウザ専用API（window や localStorage）。

  • 設計のコツ: RCCはできるだけ「小さく」保つこと。例えば、リスト全体をRCCにするのではなく、リストの中の「いいねボタン」だけをRCCにするんだ。

💡 最適化のテクニック：コンポジション

ここで、キミが得意な「委譲」や「構成」の考え方が活きてくるよ！

「RCCの中にRSCを入れることはできない」というルールがあるけど、実はchildren として渡すことで、RCCの「穴（Slot）」にRSCをはめ込むことができるんだ。

TypeScript

// 🙆‍♂️ 正しい設計例
<MyClientSidebar>
  {/* RCCの中にRSCをchildrenとして注入する */}
  <MyServerUserList /> 
</MyClientSidebar>

こうすることで、外側はインタラクティブ（RCC）なのに、中身はサーバーでレンダリングされた高速なデータ（RSC）という、最強の組み合わせが実現できるよ！

🌟 結論

キミの設計指針としては、こう考えてみて！

  1. まずは全部RSCで書くと決める。

  2. 「どうしても onClick や useState が必要だ！」となった時だけ、その部分を最小単位でRCCとして切り出す。

  3. カスタムHookは、ビジネスロジックではなく「UIの状態管理」に特化させ、RCCに持たせる。

これがNext.jsにおける、最も「キャッシュ」と「パフォーマンス」を喜ばせる、情報工学的に正しい設計だよ。

この設計論を踏まえて、キミが開発中の「AXON」での、「リアルタイムチャット部分（WebSocket等）」をどうRSCとRCCで切り分けるかについて、ディープに議論してみる？😉

Would you like me to show you a code example of how to handle real-time data while keeping the main component as a Server Component?

Prompt

葉から枝は生やせない、と思いきや、意外とそんなことはない。
でも、それをするときの条件はある？

さすが、Tiptapの「魔境」を生き抜いただけあって、Reactのレンダリングの「裏口」を直感的に見抜いているね！その通り、基本ルールは「葉（RCC）から枝（RSC）は生やせない」だけど、**「特定の条件」**を満たせば、実質的にRCCの中にRSCを組み込むことができる。

その条件とは、ズバリ**「RSCを『インポート』するのではなく、『引数（props）』として渡すこと」**だよ！

🍃 葉（RCC）の中に枝（RSC）を共存させる条件

Reactのコンパイラは、ファイルの上部にある import 文を見て、サーバー用かクライアント用かを判断するんだ。だから、RCCの中で直接 import ServerComponent from './Server' と書くと、その瞬間に枝（RSC）も無理やり「葉（RCC）」のルールに染められてしまう（クライアントで実行されてしまう）。

これを回避して「枝」のまま扱うための条件は以下の通りだよ。

1. children または props として渡す

これが最も一般的で強力な方法だ。RCCを「中身が空っぽの容器（Slot）」として設計し、親であるRSCからその中に別のRSCを流し込むんだ。

TypeScript

// 🙆‍♂️ 条件達成：親（RSC）が仲介する
// page.tsx (RSC)
export default function Page() {
  return (
    <ClientWrapper>
      <ServerList /> {/* 枝（RSC）を葉の中に放り込む！ */}
    </ClientWrapper>
  );
}

2. インポートの「境界線」を越えない

RCC側では、自分が受け取った children がRSCなのかRCCなのかを知る必要はない（そして知る術もない）。単に

{children}
とレンダリングするだけ。

この場合、ServerList は**サーバーでレンダリングされた結果（JSON/HTMLの断片）**として渡されるから、RCCの中でも「枝」としてのアイデンティティを保てるんだ。

🧪 なぜこれが重要なのか？（情工学的な視点）

キミが好きな「キャッシュ」や「凝集度」の観点から見ると、この設計には大きなメリットがあるよ。

  • ハイドレーションの最小化: RCCの範囲を最小限に抑えられる。ClientWrapper（例えばアニメーション用のコンテナ）がどんなに複雑でも、中の ServerList はJSとしてクライアントに送られない。

  • データの局所化: ServerList はDBに直接アクセスできる。これを props で渡す形にすれば、RCC側で「データをフェッチして状態管理する」という魔境化しやすいロジックを書かずに済むんだ。

⚡️ さらに「禁断の技」：Slotパターン

children 以外にも、名前付きの props を使うことで、より複雑なレイアウトも「葉の中に枝」を配置できるよ。

TypeScript

// ClientLayout.tsx (RCC)
export default function ClientLayout({ left, right }) {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <div>
      <button onClick={() => setIsOpen(!isOpen)}>Toggle</button>
      <aside>{left}</aside>  {/* ここにRSCが入る */}
      <main>{right}</main>   {/* ここにもRSCが入る */}
    </div>
  );
}

これを親のRSCで呼び出せば、インタラクティブな外枠（RCC）の中に、複数の独立した静的なパーツ（RSC）を配置できる。まさに、キミが言った「葉から枝が生えている」ような構造だね。

🌟 結論：条件は「依存性の注入（DI）」

このテクニックは、プログラミング原則で言うところの**「依存性の注入」**そのものだね。

RCCが直接RSCに依存（import）するのではなく、外部（親のRSC）から注入してもらう。

キミがTiptapで「個々の機能が密接すぎて分割が難しかった」と言っていたけど、この 「スロット（穴）を空けて、外から流し込む」 という設計思想を徹底すれば、あの魔境ももう少し見通しが良くなったかもしれないね。

次は、この「コンポジション」の考え方をさらに進めて、**「Next.jsでの状態管理（Reduxはもう古い？）」**について、最新のトレンドを話してみる？それともAXONの実装に戻る？😉

Would you like to see how this composition pattern can simplify state management in a Next.js application?

グラフビュー

最近の記事

グラフビュー