このディレクトリはプロジェクトの性質に合わせて自由に構成して頂いて構いません。
上記の理由のためUIライブラリを導入したくないので、生のCSSを買いています。なので生のCSSを書くことに従う必要はないです。
プロジェクトの性質に応じてUIライブラリを導入したりディレクトリ構造を変更して頂いて構いません。
Atomic Designはフロントエンド側で実際にコンポーネントを作る際に色々と思い通りにならない部分が多いです。
例えば、
- UIライブラリ（MUI等）を使用するとAtomic Designに沿う必要がない
- AtomsとMoleculesを分けるメリットが少ない＆チームでの認識合わせが辛い
- 結局Organismsになんでも入ってきて肥大化する
そこで次のルールにすることにしました。
- ui：見た目に関する責任を持ち、アプリケーション内で使い回すコンポーネント
- domain：ドメインに依存するロジックや状態（Redux含む）を持ち、マウントすることで期待する役割を達成できるコンポーネント
- layouts：レイアウトを調整するためのコンポーネント
- functional：カスタムフックでは対応しづらい時に使用するコンポーネント
- pages：1つのページとして動作し、ルーターで呼び出すコンポーネント
デザインを統一する目的でアプリケーション全体で使い回せるコンポーネント。
ドメインに依存せず、propsの値で振る舞いを変えることで使い回せるようにする。
また、コンポーネント自体にマージンを持つと再利用しづらいので、配置先でlayoutsコンポーネントを使用してレイアウト調整するのが好ましい。
Atomic DesignでいうAtomsやMoleculesに近い。
例：確認ダイアログ、ラベル、ボタン
ドメインや特定のStateに依存するコンポーネント。
ドメインに依存するロジックや状態を持ち、マウントすることで期待する役割を達成できることが望ましい。
Atomic DesignでいうOrganismsに近い。
例：記事一覧、入力フォーム
レイアウトを調整するためのコンポーネント。
propsでコンポーネントを受け取り、余白調整やレイアウトを調整する。
これによってuiコンポーネントでマージンを持たなくてよくなり、再利用しやすくなる。
Atomic DesignでいうTemplatesに近い。
例：ヘッダー、フッター、サイドバー、ページコンテンツ部
何らかの機能を持ち、使い回せるコンポーネント。
特定の条件によってコンポーネントのマウントを切り替えたい等、カスタムフックでは吸収しづらいものが好ましい。
例：Error Boundary、認可用のコンポーネント
ページコンポーネント。
1ページにつき1コンポーネントを作成し、React Routerでパスによってマウントする。
例：ダッシュボード、記事一覧、記事作成