新リポジトリを作るとき フロントエンドで気をつけたかった 5つのコト — 株式会社カミナシ　osuzu (@suzu415)

依存関係を定義する ① 決めたルールを守るための静的解析を導入する。 ex: eslint-plugin-strict-dependencies, dependency-cruiser ①ディレクトリベースで一方向の依存を設計して図にまとめる。 ②ディレクトリのルートはindex.tsにしてPublicAPIを明示。 ③循環参照を防ぐ。 【ディレクトリ設計だけではもったいない。依存関係も決めよう】 【依存関係を決めたら静的解析で治安を維持しよう】

ライブラリはラップして使う ①コンポーネントやhooksとしてimportするようなライブラリはラップする。 ②すべてのライブラリをラップする必要はないが、状態管理・UIはラップするメリットが大きい。 ③Routerをラップしておくとフレームワークへの依存を弱め実装を差し替えやすい。 ④UIライブラリは将来的にデザインシステムなどを社内で検討することになった際、ラップが活きる。 またImgコンポーネントのwidth, height, altをrequiredにするなどstyle以外にpropsの共通化もやりやすい。 re-exportするだけでも良いので最低限UIはラップしておくと役立つはず。 【ライブラリをラップして使うポイント】

LayoutとPageの関係を決める ①ヘッダーやメインコンテントの余白や背景を共通化したLayoutを用意する。 Layoutは全部共通化・ルーティングごとに共通化・ページごとに指定など共通化の選択肢があるので注意。 ②Routerとの組み合わせで複数ページで共通なコンポーネント(ex: Header)の再レンダリング戦略を考える。 RSC以降ならSuspense境界やハイドレーションの境界も考慮に入る。 ③Next.jsのようにLayoutが強力に仕組み化されている場合は、フレームワークのドキュメント通りに利用すれ ば問題ないはず。 【Layout層を用意して共通化】

エラーハンドリングと非同期処理の方針を決める ①非同期Read系のエラーをErrorBoundaryでcatchできる仕組みを用意する。 ②非同期Write系のエラーはtoastなどいくつかフィードバックの手段を取れるようにしておく。 ③Suspenseを採用するか決める。 宣言的に記述できコードの見通しは良くなるが、プロダクションでの利用は推奨してないライブラリもある。 ④Suspenseを採用しない場合でも、SuspenseとErrorBoundaryの境界は意識する。 【ErrorBoundaryとSuspenseで考える】

バランスとコスパを意識したテスト方針を決める ①E2Eテストはモックせずゴールデンパスのみで実施。 E2Eテストのリポジトリは独立させると複数リポジトリを跨いでテストしやすくはなる（トレードオフだが） ②ページ単位での統合テストをどの程度厚めに書くか。 ・Playwrightを用いるかtesting-libraryを用いるか。 ・モックはどうするか（ネットワークレイヤーに近づくほどFlakyになりやすいが実挙動に近づく） ③ユニットテストをどの程度厚めに書くか。 ※個人的にはComponentやhooksをユニットテストするより、ロジックのみをTSの関数としてテストするのがオススメ。 Vitestを使うとprivate methodのin-source testingも可能。 ④VRTは導入するのか。 テスト工数とFlakyテストのメンテ工数のトレードオフはある。 【テスト戦略を考える】

まとめ 1 依存関係を定義する 2 3 ライブラリはラップして使う LayoutとPageと共通コンポーネントの関係を決める 4 エラーハンドリングと非同期処理の方針を決める 5 バランスとコスパを意識したテスト方針を決める 【他にも考えた方がいいこと】 ・API Clientを型安全にする ・状態管理の戦略を決める ・Routingを型安全にする

AD We’re hiring!! カミナシはソフトウェアエンジニアを募集しています。