Reactのディレクトリ構造
※ui-componentsとdomain-componentsは分けるのは前提
componentsを下にするパターン🙆
Loading...
メリット
package by feature#ドメイン知識ごとに情報環境をわけられる Loading...
デメリット
型定義が散らばる
- featureA/
- type.ts
- featureB
- type.ts
よりは
- types/
- A
- B
のほうが見比べやすいし、ぬけもれが発生しにくい
一つのドメイン型が一つの機能に必ずしも結びつくとは限らない。
customer型はfeatureAにもfeatureBにも登場する
→それはfeature/customer
を作ってそこから呼び出すべきなのでは?
componentsを上にするパターン
Loading...
Aidemy(古河)ではこっちににしちゃったけどもう片方がいいかな?
featureが入れ子になる場合をどう考える?
experimentAとexperimentBという試験機能があって、これはexperimentに内包する。
とは言えそれぞれ独立した試験ではある。
experimentが汎用的かというとそうではない(componentsに入れにくい)
1. 同階層に置く→🙆基本的にこっちかな?
- feature
- experimentA
- experimentB
- experiment(Common?)
experiment(Common)はページが担う役割なのでは?
メリット
どこがどこに属するのか、二重に参照される機能はどうするのかとかを考えなくて良い
デメリット
やや直感的ではない
2. 内包する
- feature
- experiment
- experimentA
- experimentB
メリット
直感的
デメリット
例外が発生したときなどに対応しにくい
メモ
2023-03-13にコンポーネント整理し直したことで意味がわかってきた。