Atomic Design

エンジニアの秋山です。

プロジェクトのコンポーネントの管理にはある程度共通の認識を持ちたいので、Atomic Design を採用しています。

Atomic Design について

Atomic Design はアメリカの Web デザイナーである Brad Frost 氏が提唱したデザインシステムの設計方法です。

Atoms、Molecules、Organisms、Templates、Pagesという5つのレイヤーにわけて管理しましょうというものです。

具体的に実装していく上で、デザインシステム設計なので、コンポーネントの実装にそのまま当てはめることができない場面がでてきます。

今回は、Nuxt3でのプロジェクトでの管理としていく上での運用のルールを設計しました。

Templates、Pagesに関してはそれぞれ、layouts、pagesという概念が存在しますので、それ以外をコンポーネントとして管理することにします。

Atoms、Molecules、Organismsについては、以下のシンプルなルールを適用します。

ドメイン依存とは、プロジェクト固有や、フレームワーク固有のものを利用する場合。

コンポーネント依存というのは他のコンポーネントを利用しているかどうかというものです。

条件としては必要十分かと思いますが、状況で悩む場面がでてくるので、具体例を以下に上げます。

Moleculesです。ただ、コード量が多いと思うのであれば、Atomsに分割できるところがないか検討ください。

Vue3のコンポーネントであるならMoleculesに含めても問題ありません。Vue3以外を含む場合はOrganismsにしてください。

ref watch といったComposition APIはVue3の機能になるので、Molecules、Atomsでも大丈夫です。

Nuxtというフレームワークに依存しているのでOrganismsにしてください。コード量やサイズは関係なく、Organismsです。

適宜サブディレクトリを作成して管理してください。

Atoms、Moleculesであれば、UIフレームワークの分類が参考になるでしょう。

Organismsはプロジェクトの機能単位でつけてください。

common は使わないでください。

「ぜんぜん違うじゃん！」『……』「言ったよね！？シンプルなルールで必要十分ですって…なのに、この結果は何！」

実際のところ、Atomic Designは昔持て囃されましたが、運用つらい、そこまで必要としていないと代替がでないまま廃れ気味ではありますが、とっかかりとしては悪くないと思います。

他のプロジェクトで再利用しないのであれば、Molecules、Atomsまでわけなくてもと思いますが、後でデザイン変更や管理するときに便利だったりします。

やりすぎないことが大事で、手段が目的にならない程度にみんなが納得できるルールづくりが大事かなと思います。

よきよいコーディングライフを。