JSConf2024での、一休の@takashi_ondaさんの発表「React への依存を最小にするフロントエンド設計」を聞いた
speakerdeck.com
Reactに依存しないライブラリ選定、依存性逆転の原則や腐敗防止層といった設計思想、そして一休レストランでのRemixへの移行と具体的な実装例が紹介されている
私は特に、
- DIPのためにJotaiを用いたDIコンテナの簡易実装
- JavaScriptの新しい標準日付ライブラリ Temporalがbaselineになることを見越したDateを使わないカスタムの日付型の実装
といった実践的なテクニックが興味深かった
発表にあったReact依存最小化による利点をまとめると以下
- エコシステムの変化への対応負担軽減
- フレームワークやライブラリのバージョンアップ、新しい技術への移行など、エコシステムの変化は常に起こるので、React依存を最小限にすることで、これらの変化への追随が容易になり、メンテナンスコストを削減できる
- 一休の例として、Vue 2/Nuxt 2からNext.js App Router、そしてRemixへの移行が挙げられている
- このように、フレームワークの移行は現実的に発生しうるものであり、React依存を最小化することで、スムーズな移行を実現できる
- 長期的なプロダクト寿命の確保
- プロダクトの寿命は、使用するフレームワークよりも長くなる可能性がある
- 特定のフレームワークに強く依存した設計では、フレームワークの衰退やサポート終了に伴い、プロダクトの維持が困難になる可能性がある
- React依存を最小限にすることで、特定のフレームワークに縛られず、プロダクトを長期的に運用できる
- コードの可読性・保守性の向上
- React依存を最小化すると、コンポーネントが小さく薄くなり、ロジックがhooksに集約される
- これにより、コードの見通しが良くなり、理解しやすくなる
- また、テストが書きやすくなるため、コードの品質向上にも繋がる
また、一休がReactへの依存を最小化するために用いた技術と戦略をまとめると以下
- 技術選定
- Reactに依存しないライブラリの活用
- swrをTanStack Queryに、RecoilをJotaiに置き換えることで、Reactに依存しない形で状態管理やデータフェッチを実現
- これらのライブラリはいずれもVanilla JSで動作するため、Reactから独立した形で機能を実装できる
- 薄いフレームワークの採用
- 規約よりAPIを重視
- ファイル名やディレクトリ構造、変数名といった規約に依存するのではなく、明示的なAPIを重視することで、依存関係を明確化し、コードの可読性と保守性を向上させている
- 標準APIの尊重
- 設計
- hooksにロジックを書かない
- hooksにはロジックを記述せず、純粋な関数として実装することで、Reactコンポーネントからロジックを切り離し、再利用性を高める
- コンポーネントは薄く小さく
- JotaiによるDIコンテナ
- Jotaiで関数を管理することで、簡易的なDIコンテナとして機能させ、依存性逆転の原則を実現
- これにより、コンポーネント間の依存関係を疎結合にし、柔軟性と保守性を高めている
- 腐敗防止層
- Dateオブジェクトの代わりに独自の日付型（DateText, HourMinute, DateTimeなど）を作成することで、外部ライブラリへの依存を隔離し、将来的な変更にも対応しやすくしている
- これは、バックエンドの設計原則である腐敗防止層をフロントエンドにも適用した例と言える
これらの技術と戦略を組み合わせることで、一休はReactへの依存を最小限に抑えつつ、保守性・柔軟性・再利用性の高いフロントエンド設計を実現している
私も移行を経験したことがあるが、ライブラリの特殊な書き方は移行コストが高くするので、導入するときはそのシンタックスに気をつけていたりする
ただ、それ以外にも、規約よりもAPIを重視した設計や、標準APIの尊重などに着目することも重要だということがわかって大変勉強になった
