Atomic Designについて考えたことをまとめる
KAMY課題１ 分類の難しさ
これに関してはどうにでもなる気がする。
Atomic Designでコンポーネントを分類する場合、
- Atoms：UIの最小単位（ボタンや見出し）
- Molecules：何らかの文脈を持つパーツ・Atomsを組み合わせたパーツ
- Organisms：単体で成立する１まとまり。「〇〇エリア」と呼ばれるようなもの
上記３種が主となる。
一番厄介なのが「結局Moleculesって何？」というところだと思うが、そこの認識さえチーム内で擦り合わせてしまえば、あとは機械的に分類するだけ。
（個人的にはこの記事の内容がしっくりくる）
ただし、新メンバーが参画した際の認識あわせのコストは如何ともし難い。
これに関しては、
- ペアプロしつつ認識合わせ
- コードレビューでのフィードバック
といった地道な工程が必要になる。
KAMY課題２ Atomic Designとデータフローの不整合
前提
まず前提として、「表示を担当するコンポーネント(presentational)」と「データの取得やロジックを担当するコンポーネント(container)」を分けておきたいという考えがある。
その上で、「どの粒度でcontainerを作成していくか」と考えた場合、おそらくOrganisms単位ということになるだろう。（AtomsやMolecules単位でcontainerを切っていくと細かすぎてカオスになる。Templates / Pages 単位だと状態管理の単位として大きすぎる。）
問題
その場合に問題となってくるのが、「Moleculesでしか使わないデータもOrganisimで取得する」という点だ。
例えば、「ドロップダウンで都道府県を選択するコンポーネント」を実装する場合、Moleculesとして分類することになるだろう。
MoleculesではAPIにアクセスできないため、
- Container（Organisims単位）で都道府県一覧をAPIから取得
- Molecules（都道府県を選択するコンポーネント）にPropsとして渡す
という工程が必要になる。
そのコンポーネントを１つのOrganisimsでしか使用しないならさほど問題にもならない。しかし、複数のOrganisimsで利用する場合、上記の工程を毎回繰り返す羽目になる。
Reactの場合、データ取得をhooksに切り出せば処理をまとめられるが、その場合は「都道府県を選択するコンポーネント」とhooksの間に暗黙の依存関係が生じる。
できれば、「都道府県を選択するコンポーネント」内で都道府県一覧を取得しておきたい。
対策
そもそも、Atomic Designはデザイン上の文脈で提唱された考え方だ。それをフロントエンドの実装時に直接持ち込んでもフィットしないのかもしれない。
裏を返せば、「デザイン上の分類」と「実装上の分類」を分けて設計すればいいのでは？
- Applicationコンポーネント
- ロジックを持つ
- APIと接続する
- コンポーネントの粒度には関係なし
- 内部で下記のCommonコンポーネントを呼び出すこともある
- Commonコンポーネント
- Applicationコンポーネントに呼び出される
- APIと接続しない。UIの状態（メニューの開閉など）以外のロジックは持たない
- 中規模以上の開発の場合、 Commonコンポーネント内部で粒度ごとに分類する（ここで初めてAtomic Designを利用）
という設計を考えてみたので、そのうち試してみたい。