Atomic Designとは
AtomicDesignとは、何かを簡単に言うとUIを構成している部品を「Atoms(原子)」「Molecules(分子)」「Organisms(有機体)」と分類して、それらを「Templates(テンプレート)」「Pages(ページ)」といった概念で組み合わせて作り上げる設計・実装の手法です。
簡単に言うと、UI コンポーネントの粒度をカテゴリーに明確に分ける手法のことです。
メリット
- 部品が共通化されているので広範囲の修正が容易に可能。
- コンポーネントの責務がより明確になる。
- 見た目の粒度だけでなく、ロジックの責務も明確にできる。
- 並列作業や分業が非常にしやすい
- 部品の使い回しが非常に楽
- 世間的にも浸透している概念のため、デザイナー・エンジニア間の共通言語を作れる
デメリット
- AtomicDesignの概念をそのまま導入すると要件に合わない場合がある。
- チーム内でルールを制定した方が良い場合もある。
- メンバー間の認識合わせにとても時間がかかる。
- 概念や設計が破綻しないように部品を考える必要がある。
カテゴリー
Atoms
Atomsには基本的なスタイルだけを指定し、色やpadding、widthなどは変更できるようにつくります。最小の粒度のコンポーネント
で、どれをAtomsにするかの判断は難しいので、デザイナーに一任するのも一つの手です。
例)Button, Icon, Text, Title ...etc
Molecules
Atomsを組み合わせ
て作り上げます。
使っているAtomsの色やpadding、width、などはここで指定します。
しかし、Moleculesは汎用的に使うことができる(複数organismsから参照される)ように、Molecules自体のwidthやmarginなどは(基本的には)ここでは指定しません。
例)Card, Box, Form, Popup ...etc
Organisms
AtomsやMoleculesを組み合わせ
て作ります。
使っているMoleculesやAtomsのmarginやwidthはここで指定します。
しかしOrganismsは汎用的に使うことができるよう、Organisms自体のwidthやmarginなどは(基本的には)ここでは指定しません
。
もしも、ロジックを持つ場合は表示を制御するコンポーネントと分けて実装すると良い。
例)Header, Calendar, Modal, CardList ...etc
Templates
こちらは中身のないレイアウトのテンプレート
で、コンテンツのwidthや、paddingなどが含まれます。つまり、コンポーネント自体の横幅を指定しなかったことがここで活きてくるのです。
Templatesは、ロジックを持たず、pagesコンポーネントから1ページ/1回だけ呼び出されます。
DOMツリーの最もrootに近い場所にレンダリングされます。
例)MainContents, MainContentsWithSideBar …
Pages
Pagesには、これまでのコンポーネントに実際のテキストや画像を流しこみます。
このページ特有のOrganismsのmarginなどはここで指定します。汎用的につくることは意識しませず、APIリクエストやルーティング関連の処理(基本的にRouteコンポーネントの直下にレンダリングされる)はここで行います。
Atomic Designの粒度に分けたコンポーネントを確認する
コンポーネントの見た目は?どのAtomsを使えばいいか?等、コンポーネントの確認を行いたいときに、StorybookというReactコンポーネント開発用ツールを使用しています。
コンポーネントのUIを一覧で確認することができます。
参考
[Yahoo! JAPAN トップページを Atomic Design と React・Redux・TypeScript で作り変えたお話]
(https://techblog.yahoo.co.jp/entry/20191203785540/)
[Atomic Designを使ってReactコンポーネントを再設計した話]
(https://blog.spacemarket.com/code/atomic-design%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6react%E3%82%B3%E3%83%B3%E3%83%9D%E3%83%BC%E3%83%8D%E3%83%B3%E3%83%88%E3%82%92%E5%86%8D%E8%A8%AD%E8%A8%88%E3%81%97%E3%81%9F%E8%A9%B1/)
[React で実装する atomic design のコンポーネントごとの責務の分け方とコード規約]
(https://qiita.com/takano-h/items/8731d8e7413d7b1f6d7b)
[Atomic Designをやめてディレクトリ構造を見直した話]
(https://note.com/tabelog_frontend/n/n07b4077f5cf3)