シェアフル Advent Calendar 2018 3日目の記事です。
ここ一年くらい複数のプロジェクトでAtomic Designを取り入れてやっていたので、その辺の話を開発者視点で書いていこうと思います。
Atomic Designとは
解説については↑のサイトを参照
コンポーネントの種類
Atomic Designでは以下の種類のコンポーネントに分けて実装
- Atoms
- Molecules
- Organisms
- Templates
- Pages
個人開発プロジェクトで採用しているので実装例を元に各種類について解説します
Atoms
最小単位のパーツコンポーネント 「テキスト」、「画像」、「テキスト入力」、「チェックボックス」、「セレクトボックス」等々が該当します
Molecules
Atomsを2つ以上組み合わせたコンポーネント
Organisms
MoleculeとAtomsを組み合わせて1機能として自己完結しているコンポーネント
MoleculeとOrganismsの違いについては下記の記事を読むと分かりやすいです。 frasco.io
Templates
Organisms、Molecule、Atomsを組み合わた1画面のコンポーネント
Pages
Templatesに実際の情報を組み込んだ最終的なコンポーネント
開発での実装
採用しているプロジェクト情報
- react-native (expo)で実装
フォルダ構造
- src/components/ 以下に、「atoms」〜「 pages」のフォルダを作成し該当するコンポーネントを作成している
Shiori/ShioriNative/src/components at master · wheatandcat/Shiori · GitHub
storybookとの連携
storybookはコンポーネント単位の表示を管理ツールできるツールです storybookの詳しい情報は下記参照
Atomic Designに合わせてstorybookファイルを作成しコンポーネントを管理しています
Atomic Designを採用してみての話
明確なメリット
問題点
理解力の差によって配置されるべきコンポーネントに差異が起きる
- 上記にもリンクを貼っているがMoleculeとOrganismsは特に誤った配置がされやすいので注意が必要
十分に注意してコード修正、レビューを行わないと負債になりやすい
- リファクタリングの際にコンポーネントの役割が「Atoms→Molecule」や「Molecule→Organisms」に変更されたが、フォルダの移動がされずに放置され負債になるケースが起きやすい
- 上記の負債はあくまで「Atomic Design」での誤りなので、もちろんテストコードでは分からず、またコードレビューのみでは分かりづらい。なので定期的なstorybookでのチェック and リファクタリングコストをかける必要がある
Atomsにするか個々のコンポーネントに書いてしまうか悩む
まとめ
- 一年間かけて徐々に理解力が深まっている感じはする
- 問題点はあるが、それでも何も基準無しに作るのよりは大きくマシだと言えると思う
- コードレビューだけだと間違いを見逃すからstorybookは必須だと思う（もちろん、理想は自動テストだけど。。。）
実際のコンポーネントを確認したい人は
- 以下でstorybookのアプリを公開しているのでexpoからご確認ください 🙇
