Reactのディレクトリ構造 ※ui-componentsとdomain-componentsは分けるのは前提

componentsを下にするパターン🙆

- feature(domain)
	- featureA
		- utils.ts
		- types.ts
		- SomeComponent1
		- SomeComponent2
	- featureB
- components
	- layouts
	- ui
	- functional
- pages
	- FeatureAB

メリット

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

Loading...

デメリット

型定義が散らばる

- featureA/
	- type.ts
- featureB
	- type.ts

よりは

- types/
	- A
	- B

のほうが見比べやすいし、ぬけもれが発生しにくい

一つのドメイン型が一つの機能に必ずしも結びつくとは限らない。

customer型はfeatureAにもfeatureBにも登場する
→それはfeature/customerを作ってそこから呼び出すべきなのでは？

componentsを上にするパターン

- components
	- layouts
	- ui
	- functional
	- domains
		- featureA
- pages/
	- FeatureAB

Aidemy（古河）ではこっちににしちゃったけどもう片方がいいかな？

featureが入れ子になる場合をどう考える？

experimentAとexperimentBという試験機能があって、これはexperimentに内包する。
とは言えそれぞれ独立した試験ではある。
experimentが汎用的かというとそうではない（componentsに入れにくい）

1. 同階層に置く→🙆基本的にこっちかな？

- feature
	- experimentA
	- experimentB
	- experiment(Common?)

experiment(Common)はページが担う役割なのでは？

メリット

どこがどこに属するのか、二重に参照される機能はどうするのかとかを考えなくて良い

デメリット

やや直感的ではない

2. 内包する

- feature
	- experiment
		- experimentA
		- experimentB

メリット

直感的

デメリット

例外が発生したときなどに対応しにくい

メモ

2023-03-13にコンポーネント整理し直したことで意味がわかってきた。