概要
私は普段、Vue.js と Ruby on Rails を使用して開発しています
フロントエンドにはアトミックデザインを採用しています
ここでは、開発を進める中で「最初からこうしておけばよかった」と感じた点や「ここがよかった」という点をまとめています
そもそもアトミックデザインって？
ざっくりといえば個々のUIコンポーネントのデザインと再利用に焦点を当て、効率的で一貫したデザインシステムを構築するためのアーキテクチャです
以下はディレクトリ構成の例です
- /components/: コンポーネントがアトミックデザインの階層に基づいて構造化されて配置される
- atoms: 最小のUIコンポーネント（例：ボタン、入力フィールドなど）
- molecules: 複数の原子を組み合わせたコンポーネント（例：フォームグループ、ナビゲーションバーなど）
- organisms: より大きなUI構造（例：ヘッダー、フッター、製品リストなど）
- templates: ページ全体のレイアウトテンプレート
- /pages/: 各ページコンポーネントが配置される
- /utils/: アプリケーション全体で使用されるユーティリティ関数
開発してきてわかったこと
atomsやmoleculesコンポーネントでデータ取得処理は可能な限りさせないこと
これらのコンポーネントにデータ取得の処理を埋め込むと、コンポーネントが特定のAPIやビジネスロジックに依存してしまい、再利用性が損なわれる
このため、atoms や molecules は、できるだけ汎用的で再利用可能なものにしたい
これを避けるため、データ取得や状態管理などの処理は行わず、親コンポーネントから必要なデータやコールバックをプロパティ（props）として渡すようにする
再利用性を意識しすぎないこと
再利用可能なコンポーネントを作ろうとしても、細かいカスタマイズが必要になることがあります
結果として利用性の高いコンポーネントを作ることに集中しすぎて、かえって開発が遅くなったり
複雑なプロパティを追加したがためにコンポーネントが使いにくくなることも
これを避けるため、こうしたときは、別コンポーネントとして構築してしまうのがよいかと思う
ただし、あまり自由にしすぎるとアトミックデザインのよさが失われるのも事実のため、ほどほどに
コンポーネントの共有をできていること
再利用可能なコンポーネントを作ったはいいものの、それが周知されず同様のコンポーネントを作ってしまうことがある
これを避けため、デザインガイドライン等でメンバーが迷わないようにしたい
バグを生みにくい
一度作成したコンポーネントを再利用することで、同じロジックやUIを何度も実装する必要がなくなり、設計ミスや実装ミスが少ない
小さなコンポーネントはユニットテストがしやすく、テストカバレッジを高めやすい
最後に
どんなアーキテクチャもそうですが、使い方を誤ったまま続けると後から修正が大変になるかと思います
導入前に調査内容をまとめておくことももちろん大切ですが
今回のように教訓や反省を元にまとめることも大事かと思った次第です