フロントエンドのディレクトリ構成どうしてる？ Feature-Sliced Design 導入体験談

「関西フロントエンド忘年会2024 HACK.BAR × KINTOテクノロジーズ」のLTで発表したスライドです。
https://kinto-technologies.connpass.com/event/337002/

Transcript

1. フロントエンドの ディレクトリ構成どうしてる？ 2024/12/06 Feature-Sliced Design 導入体験談
2. 自己紹介 楢林 祐輝 / Yuki Narabayashi KINTO テクノロジーズ株式会社 フロントエンドエンジニア
3. Agenda 1 Feature-Sliced Design を導入した理由 2 どう使ったか 3 導入して感じたメリットと遭遇した問題 4 まとめ 5 6 アジェンダ
4. 参考）いま開発している Web アプリの技術スタック（フロントエンド）
5. Feature-Sliced Design を導入した理由 1
6. 突然ですが。。。 フロントエンドの ディレクトリ構成どうしてますか？
7. Atomic Design
8. Bulletproof React
9. Clean Architecture
10. これらの選択肢について自分が感じた課題とほしかったもの • Atomic Design のルール（依存関係）は明確でわかりやすい • しかしルール上、ロジックや UI が散らばる傾向にあり、成長ととも にどんどん可読性・参照性が落ちていく • Bulletproof React はその課題をクリアした（と自分は思っている）が、 代わりに共通コードのルールが薄くなってしまったように感じる 課題感 • Atomic Design が持つような、依存関係のルール • co-location できる構成（まさに features にまとめる、みたいな） ほしいもの
11. Feature-Sliced Design の全体像
12. Feature-Sliced Design の絵を見た時の率直な感想 Atomic Design っぽい…… features ってあるし Bulletproof React の要素もありそう…… もしかしたらいいとこ取り？ とりあえずやってみよう！
13. どう使ったか 2
14. 使い方の前に そもそも Feature-Sliced Design ってどういうもの？
15. Feature-Sliced Design の構造（Layers） 7 つのレイヤー（うちひとつは非推奨） 下の階層のみ参照でき、親の参照は禁止 これが基本ルール
16. Feature-Sliced Design の構造（Slices） Layers の中身でドメイン別に分離する （shared・app 以外のレイヤーのみ） 同じレイヤー内の Slices 同士は原則参照禁止 UI・ロジックをまとめてカプセル化する Slices を import して利用する （Public API）
17. Feature-Sliced Design の構造（Segments） 各 Slices の中身 命名以外に明確なルールはない この中にコードを配置する
18. 自分は Feature-Sliced Design をこう使ってみました（shared） 共通で使える UI や便利関数を置く ドメインに関係するようなものは置かない
19. 自分は Feature-Sliced Design をこう使ってみました（entities） REST API の fetch 関数や エンティティの型定義（Zod とか）を配置 ここにコンポーネントは置かなかった
20. 自分は Feature-Sliced Design をこう使ってみました（features） メインロジックやコンポーネントなど コアになる部分を配置 とにかくここにどんどんまとめていく
21. 自分は Feature-Sliced Design をこう使ってみました（widgets） 複数の features を使うコンポーネントを配置 多用はしないものの、使ってはいる
22. 自分は Feature-Sliced Design をこう使ってみました（pages） ページ用コンポーネントを配置 下位レイヤーの部品を組み合わせて構成 （運用は模索中、詳細は後ほど） Remix の /routes とはあえて別にした
23. 自分は Feature-Sliced Design をこう使ってみました（app） Context API の Provider や Global な CSS など （Remix の /app と区別するため /application というディレクトリ名にした）
24. 自分は Feature-Sliced Design をこう使ってみました（processes は？） 未使用 非推奨、とのことなので採用せず ちなみに、利用したくなった場面は一度もない
25. 導入して感じたメリットと遭遇した問題 3
26. 導入してみてメリットを実感できたこと Web アプリの規模が拡大しても、問題なくそのまま拡張できた 途中で計画見直しが入り、開発当初からおよそ 3 倍ぐらいの規模（小規模→中規模程度）になった しかし構造が破綻することはなく、そのままの方針で走り切ることができた その２ ねらい通り、コードがまとまって可読性が向上した Layer・Slice ごとにまとまっているので、Atomic Design 採用で感じた課題はクリアできたと実感 コードを配置すべき位置も相対的に判断しやすくなり、構造に悩まず開発できた その１ リファクタリングがしやすくなった（かもしれない） 依存関係が低結合かつ明確になったので、ある程度のリファクタリングはしやすくなった （影響箇所がわかりやすくなった、というレベルです。もちろんリファクタリング後はテストします） その３
27. 途中で遭遇した問題とその対策１ 問題 思ったより自由度が高かった 7 つのレイヤーとその構成以外にそこまで明確なルールがない 当時はドキュメントがなく、Examples を頼りに考えるしかなかった 対策 チームメンバーの開発前にルールを作ってドキュメント化した ルールがないならルールを作るしかない フィーリングの合う Example を参考に、開発前にルールを明確にした 不足・不都合が出たら都度改善していった
28. 途中で遭遇した問題とその対策２ 問題 型定義でどうしても同じレイヤーの他の Slice を参照したかった 本来同じレイヤー内の Slice は相互参照禁止のルールがある しかし、entities（型定義）では相互参照しないと成立しない場面があった 対策 @x ディレクトリを使用した相互参照ルールを採用した entities は @x ディレクトリを採用して事なきを得た（詳細は割愛） 当時、この運用はルールとして明示されておらず GitHub に記載されていた。 （いまはルールに組み込まれています ）
29. 途中で遭遇した問題とその対策３ 問題 pages レイヤーの使い方が難しい。。。 ページを構成するレイヤーだが、これを多用すると Atomic Design の課題（コー ドがちらばってしまう問題）が再発する pages レイヤーをどう使うべきか。。。 対策 pages レイヤーでは下位レイヤーの持つ部品の組み合わせを意識 可能な限り、pages レイヤーに独自のコードを定義せず、 features レイヤーに押し込める かつ、Remix のルーティングとの接続部分として使う方針とした （本当は /routes ＝ pages レイヤーにするのがベストなのかも？）
30. 途中で遭遇した問題とその対策４ 問題 親レイヤーを import してしまった 当時、良い対処方法を知らず、人力チェックで運用していた しかし、いつの間にか親レイヤーが持つ機能を import してしまった さすがに人力でチェックするには限界があった 対策 ESLint で自動的に検出できるように eslint-plugin-boundaries という便利なプラグインがある これを lint チェックに組み込むことで自動的に誤りを検出できるようになった （他に公式の @feature-sliced/eslint-config というプラグインもあります）
31. 参考）eslint-plugin-boundaries 各レイヤーの ディレクトリを element として定義する 各レイヤーの import ルールを定義する （エラーを検知できる）
32. 参考）他にも steiger という公式の linter がある https://github.com/feature-sliced/steiger ベータ版ですが、Feature-Sliced Design 専用の linter があります。 公式ドキュメントでもこちらの利用を推奨されています。 （しかし未使用なので使い勝手はわからず。。。） README を見る限りはかなり厳密にチェックされてそうです。 ESLint ではなく、こちらを導入するのも良いかもしれません。
33. まとめ 4
34. （再）他の構成について自分が感じた課題とほしかったもの • Atomic Design のルール（依存関係）は明確でわかりやすい • しかしルール上、ロジックや UI が散らばる傾向にあり、成長ととも にどんどん可読性・参照性が落ちていく • Bulletproof React はその課題をクリアした（と自分は思っている）が、 代わりに共通コードのルールが薄くなってしまったように感じる 課題感 • Atomic Design が持つような、依存関係のルール • co-location できる構成（まさに features にまとめる、みたいな） ほしいもの
35. （再）他の構成について自分が感じた課題とほしかったもの • Atomic Design のルール（依存関係）は明確でわかりやすい • しかしルール上、ロジックや UI が散らばる傾向にあり、成長ととも にどんどん可読性・参照性が落ちていく • Bulletproof React はその課題をクリアした（と自分は思っている）が、 代わりに共通コードのルールが薄くなってしまったように感じる 課題感 • Atomic Design が持つような、依存関係のルール • co-location できる構成（まさに features にまとめる、みたいな） ほしいもの Feature-Sliced Design はどうだった？ • 当初の目論見どおり、Atomic Design と Bulletproof React のいいとこ取りの運用ができた • 都度、工夫しながら、大きな問題なく安定して開発でき ている
36. まとめ もし似たような課題感をお持ちであれば Feature-Sliced Design は 選択肢のひとつになると思います
37. Feature-Sliced Design v2.1 がリリースされました 11 月に v2.1 リリース 日本語のドキュメントも増えて とっつきやすくなりました
38. Thank you !