フロントエンド(React)のディレクトリ構成
tosuke.iconがフロントエンドをReactでやっていくときによくやっている
全体
components/
Hoge/
ui/
index.ts
Text/
features/
auth/
routes/(pages/)
index.tsx
components
コンポーネントを置く
基本的にフラットにコンポーネントのディレクトリを切って、そこで1つ1つのコンポーネントを書く
1つのコンポーネントディレクトリは(意味的に)1つのコンポーネントをexportする
リストとそのアイテムみたいな、必ずその組み合わせで使うコンポーネントは1つとしてカウントする
巨大になると困りそうだけど、巨大になったときの知見がない。教えてほしい
最近はより簡単に，Hoge.tsxとHoge.test.tsxを書くというのもやることがある
この2つしかないなら破滅しない
ui
UIコンポーネントを書く
Atomic Designで言うとAtoms
components/uiで配下の全てのコンポーネントがimportできるようにしているようにしているが、単にそうしないと煩雑になりがちというだけで特に何か考えているわけではない
これも巨大になったときの知見がない。教えてほしい
features
状態管理とデータ取得に関連する処理を書いていく
Redux ToolkitのExampleに書いてある設計を拝借してきただけなので知見がない
Clean ArchitectureにおけるUsecaseとDomain両方の役割を持つが、どちらに寄せるのがベストなのかわからん
Reduxはそのイベント指向な設計によってドメイン横断的な処理を他スライスのActionを購読することで行えるのでDomainに寄せて問題ない
routes
Next.jsの場合pages
ルーティングによってcomponentsの内容(とルータがデータ取得も担う場合featuresも)を合成していく
このとき各ルートにはロジックは極力書かない
と言いつつNext.jsの書き味だとプロトタイピングしているときは書きがち(そしてそのまま残りがち)。反省
コンポーネント
思想としては、コンポーネントの見た目(スタイル、Story)、ロジック(テスト)、要求するデータ(GraphQLのクエリなど)は一箇所にまとめられるべき
こういったものが(例えばコードをその役割ごとに分類するディレクトリ構成によって)分散されてしまうと、それはもはやコンポーネントとは呼べなくなってしまう
あるコンポーネントを外部に公開するのはかなり責任が求められるので、できるなら公開するコンポーネントは最小限に留めたい
「コンポーネントの一部となるコンポーネント」を他の関係ないコンポーネントが使う状況を避けたい
例
Hoge/
index.ts
Hoge.tsx
Hoge.test.tsx
Hoge.stories.tsx
useHoge.ts
useHoge.test.ts
HogeItem.tsx
HogeItem.module.css
HogeItem.test.tsx
index.ts
exportだけやる
コンポーネントに従属する(が公開されてほしくない)実装が外部で利用されることを防ぐ
もちろん利用している実装をレビューやLintで弾く文化が必要
Ctrl-Pでindex.tsxが並んでどれがどれだかわからなくなる状況を避けたいというのもある
HogeItem.tsx(別に名前が~Itemである必要はない。ディレクトリ名と同じでなければ何でもよさそうだ)
見た目部分を構成するコンポーネントを書いていく。つまりfeaturesは触らない
Atomic DesignのMoleculesに相当すると思っている
見た目を組むときはこれとHoge.stories.tsxを使って試しながら書いていく
Hoge.stories.tsx
Storybookを書く
Hoge.tsx
メインのコンポーネントを書いていく
Atomic DesignのOrganismsに相当すると思っている
下位のコンポーネントを使って、表示する内容の論理構造を表現する
スタイルやレイアウトのことを知らないように努力する
ちゃんと分割されていると下位のコンポーネントと既に定義されたhookを合成するだけになるはず
そうなりたい
だいたい上位コンポーネントにベタ書きしながら分割を繰り返して書いていくので、ここに<div>とか生えがち
分割の残り
展望
テストやStoryも同じファイルに書けたらファイル数を減らせて楽な気がする
より「実装に関するドキュメント」としてテストとかを書きたい
#フロントエンド