| 選択肢 | 概要 | 現状 |
|---|---|---|
| Inertia.js | コントローラから直接 props を渡す。API 層不要 | Laravel で標準化済み。Rails 側も活発 |
| React on Rails | Rails ビュー内で React を SSR/CSR | ShakaCode 1社依存。広がりは限定的 |
| Vite Rails + SPA | Vite で React SPA をビルド・配信 | ビルドツール統合であってフレームワークではない |
| jsbundling-rails | Rails 標準のバンドラー統合 | シンプルだが React との連携は自前設計 |
この中だと Inertia.js が一番スタンダード。
| 観点 | Inertia | Next.js + Rails API |
|---|---|---|
| API 設計 | 不要 | 必要 |
| デプロイ | 1つ | 2つ |
| モバイル対応 | 別途 API が必要になる | そのまま使える |
| 型の同期 | 手動 | GraphQL/OpenAPI codegen で自動化可 |
| SSR | Node プロセス追加で対応可 | 標準で組み込み |
| RSC / Streaming | 非対応 | 対応 |
| チーム分業 | しにくい | しやすい |
| 立ち上げ速度 | 速い | 遅い |
複雑さの総量は変わらない。どこに寄せるかだけ。
SSR のパフォーマンスより、RSC が必要かどうかで選ぶ方が現実的。
| 観点 | Hotwire | React |
|---|---|---|
| 思想 | サーバーが HTML を返す | クライアントが状態から描画 |
| 構造化 | Stimulus コントローラ | コンポーネント |
| 型安全 | なし | TypeScript |
| 状態管理 | サーバー側 | エコシステムが豊富 |
| テスト | Rails のシステムテスト寄り | Testing Library, Storybook |
| フロント複雑化時 | 仕組みがない | 対応できる |
jQuery 的な匂いがする。スコープが閉じている分マシだが、宣言的 UI やコンポーネント指向とは違う世界。
| 構成 | 型の同期方法 |
|---|---|
| Inertia | 手動定義。ズレは実行時まで気づけない |
| Inertia + types_from_serializers | シリアライザから生成。まだ成熟していない |
| 分離構成 + GraphQL codegen | スキーマから自動生成 |
| 分離構成 + OpenAPI codegen | スキーマから自動生成 |
| 条件 | うまくいく | 辛くなる |
|---|---|---|
| 島の数 | 少ない（1〜2個） | 多い（5個以上） |
| 島同士の連携 | 不要 | state を共有したい |
| 島の役割 | 独立した入力装置 | ページ全体の制御 |
島が増えて連携し始めたら「最初から全面 React で」となるパターンが多いらしい。
