App

Loading...

package by feature#ドメイン知識ごとに情報環境をわけられる

Test

Unitテストやコンポーネントテストは対象ファイルと同階層に配置する
結局テストファイルはどこに置くのがベターなのか

Components

- /src/components
  - /app             # applicationで使用されるdomainに紐づいたパーツ: 基本的にHeader/Sidebar/Footer/Searchとかのみ
  - /functional      # 見た目を伴わない/hooksでも良いが、keyevent、login判定などはcomponentで囲みたい : ErrorBoundary, Suspenceはここ
  - /layouts         # pageやpartsのレイアウト
  - /ui              # 見た目を伴う/domainに関心を持たない/componentの用途や大小は問わない
    - /elements    # stateを持たない
    - /parts       # stateを持っても良い(fetchはしない)

• ui-elementsにするならui/elementsの方が良い
• どんなに複雑でもドメイン知識が入らないコンポーネントはui/xxx

Features

- /src/features/some-feature
  - /api
  - /assets
  - /components
  - /constants
  - /hooks
  - /routes
  - /stores
  - /testings
  - /types
  - /utils
  - index.ts # 各featureのエントリーポイント / 与えられた機能の公開APIとして機能 / 機能の内、「外部」で使用されるものをエクスポート

• domainに関心を持ち、単体でサービスが成り立つレベル
• src配下をフラクタルにするようなイメージ
• 特定の機能にのみ依存する内容
  • featuresに配置するかどうかはfeatureを消したときにそのファイルも消えるかどうかで判断する
  • 複数機能またぐ様になったらsrcに移行する
  • 共通化を頑張らないことが大事

🧾Reactのディレクトリ構造を考える@2023-03-13#featureが入れ子になる場合をどう考える？

Component構成

/Hoge
  - /SubComponent
  - Hoge.tsx
  - (Hoge.module.css) --- cssmodulesを使う場合
  - Hoge.stories.tsx
  - index.ts

• 共通ファイル生成ツールを使う
• すべて同じ階層にしなくても良い / 入れ子にしても良い
  • デメリットは整理されてない感があるだけ

- /components
  - /DropDown
  - /Tabs
    - /TabPanel
    - /TabHeader

依存ルール

自分と同階層か下にあるコンポーネントのみインポートして良い。
tsファイルのインポートルール

• components

• ui

参考

• bulletproof-react
• Reactのディレクトリ構成でAtomicデザインをやめた話
  • SPA Componentの推しディレクトリ構成について語るも含む
• Atomic Design
• Reactのディレクトリ構成を考える
• tsファイルのインポートルール
• モダンフロントエンドで始めるつらくないReactディレクトリ構成

タグ

React
ディレクトリ構造
開発

Changelog