Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

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

OsakaTechLab
December 08, 2024

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

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

OsakaTechLab

December 08, 2024
Tweet

More Decks by OsakaTechLab

Other Decks in Programming

Transcript

  1. これらの選択肢について自分が感じた課題とほしかったもの • Atomic Design のルール(依存関係)は明確でわかりやすい • しかしルール上、ロジックや UI が散らばる傾向にあり、成長ととも にどんどん可読性・参照性が落ちていく

    • Bulletproof React はその課題をクリアした(と自分は思っている)が、 代わりに共通コードのルールが薄くなってしまったように感じる 課題感 • Atomic Design が持つような、依存関係のルール • co-location できる構成(まさに features にまとめる、みたいな) ほしいもの
  2. Feature-Sliced Design の絵を見た時の率直な感想 Atomic Design っぽい…… features ってあるし Bulletproof React

    の要素もありそう…… もしかしたらいいとこ取り? とりあえずやってみよう!
  3. 自分は Feature-Sliced Design をこう使ってみました(app) Context API の Provider や Global

    な CSS など (Remix の /app と区別するため /application というディレクトリ名にした)
  4. 導入してみてメリットを実感できたこと Web アプリの規模が拡大しても、問題なくそのまま拡張できた 途中で計画見直しが入り、開発当初からおよそ 3 倍ぐらいの規模(小規模→中規模程度)になった しかし構造が破綻することはなく、そのままの方針で走り切ることができた その2 ねらい通り、コードがまとまって可読性が向上した Layer・Slice

    ごとにまとまっているので、Atomic Design 採用で感じた課題はクリアできたと実感 コードを配置すべき位置も相対的に判断しやすくなり、構造に悩まず開発できた その1 リファクタリングがしやすくなった(かもしれない) 依存関係が低結合かつ明確になったので、ある程度のリファクタリングはしやすくなった (影響箇所がわかりやすくなった、というレベルです。もちろんリファクタリング後はテストします) その3
  5. 途中で遭遇した問題とその対策2 問題 型定義でどうしても同じレイヤーの他の Slice を参照したかった 本来同じレイヤー内の Slice は相互参照禁止のルールがある しかし、entities(型定義)では相互参照しないと成立しない場面があった 対策

    @x ディレクトリを使用した相互参照ルールを採用した entities は @x ディレクトリを採用して事なきを得た(詳細は割愛) 当時、この運用はルールとして明示されておらず GitHub に記載されていた。 (いまはルールに組み込まれています )
  6. 途中で遭遇した問題とその対策3 問題 pages レイヤーの使い方が難しい。。。 ページを構成するレイヤーだが、これを多用すると Atomic Design の課題(コー ドがちらばってしまう問題)が再発する pages

    レイヤーをどう使うべきか。。。 対策 pages レイヤーでは下位レイヤーの持つ部品の組み合わせを意識 可能な限り、pages レイヤーに独自のコードを定義せず、 features レイヤーに押し込める かつ、Remix のルーティングとの接続部分として使う方針とした (本当は /routes = pages レイヤーにするのがベストなのかも?)
  7. 途中で遭遇した問題とその対策4 問題 親レイヤーを import してしまった 当時、良い対処方法を知らず、人力チェックで運用していた しかし、いつの間にか親レイヤーが持つ機能を import してしまった さすがに人力でチェックするには限界があった

    対策 ESLint で自動的に検出できるように eslint-plugin-boundaries という便利なプラグインがある これを lint チェックに組み込むことで自動的に誤りを検出できるようになった (他に公式の @feature-sliced/eslint-config というプラグインもあります)
  8. 参考)他にも steiger という公式の linter がある https://github.com/feature-sliced/steiger ベータ版ですが、Feature-Sliced Design 専用の linter

    があります。 公式ドキュメントでもこちらの利用を推奨されています。 (しかし未使用なので使い勝手はわからず。。。) README を見る限りはかなり厳密にチェックされてそうです。 ESLint ではなく、こちらを導入するのも良いかもしれません。
  9. (再)他の構成について自分が感じた課題とほしかったもの • Atomic Design のルール(依存関係)は明確でわかりやすい • しかしルール上、ロジックや UI が散らばる傾向にあり、成長ととも にどんどん可読性・参照性が落ちていく

    • Bulletproof React はその課題をクリアした(と自分は思っている)が、 代わりに共通コードのルールが薄くなってしまったように感じる 課題感 • Atomic Design が持つような、依存関係のルール • co-location できる構成(まさに features にまとめる、みたいな) ほしいもの
  10. (再)他の構成について自分が感じた課題とほしかったもの • Atomic Design のルール(依存関係)は明確でわかりやすい • しかしルール上、ロジックや UI が散らばる傾向にあり、成長ととも にどんどん可読性・参照性が落ちていく

    • Bulletproof React はその課題をクリアした(と自分は思っている)が、 代わりに共通コードのルールが薄くなってしまったように感じる 課題感 • Atomic Design が持つような、依存関係のルール • co-location できる構成(まさに features にまとめる、みたいな) ほしいもの Feature-Sliced Design はどうだった? • 当初の目論見どおり、Atomic Design と Bulletproof React のいいとこ取りの運用ができた • 都度、工夫しながら、大きな問題なく安定して開発でき ている