はじめに

N番煎じですが、Atomic Designで開発していてAtomsの扱いに困ったので、再考察していこうと思います。

Atomsで困った点

Buttonコンポーネントは他のコンポーネントが子要素として入ってくるけど、Atomsに入れて良いのか？という点で困りました。

この問題に関して、「Atomic Designってデザイナーには難しくない！？という話」の中で考察されているので、これで良いんじゃないか？と思う人もいるかもしれませんが、実際に実装していくと上手くいかない部分が出てくるので、再考察していきます。

先ほどの記事で取り扱われているButtonコンポーネントの実装はこのようになっています。

button.tsx

import React from 'react';

const Button = ({ onClick, children }) => (
  <button onClick={event => onClick(event)}>{children｝</button>
);

export default Button;

これって、childrenに空のdivのようなコンポーネントが入ってきたときに、機能として完結していると言えるでしょうか？また、このButtonコンポーネントを使用して実装した単なる矩形のボタンを、Moleculeとするのは違和感があるのではないでしょうか？

このコア機能をもったButtonクラスはロジック部分を担当するので、UIコンポーネントのAtomsに入れるのは違和感がありました。

そこで調べたところ、書籍「Atomic Design」の著者 Brad Frost 氏の考えについての翻訳記事「アトミックデザインの拡張 - Extending Atomic Design」がありましたので、この中で述べられているdesign tokenについて紹介しようと思います。

Extending Atomic Design

design tokensは次のように説明してあります。

例えば「color-brand-blue（青が混ざった色）」というデザイントークンは、UIの重要な要素ではありますが、それだけでは機能しません。これを機能させるには、ボタンの背景色といったものを定義している「Atom」に適用する必要があります。

Atomに適応しないと機能しないが、再利用性の高いものであることがわかります。Colorに関してはAtomsに入れるような（UIデザイン的な面から考えて）記事も見たことありますが、Atomsより小さいIonsのような階層で管理するかCSSのフレームワークで管理する方が直感的な気がします。ちなみにIonsはdesign tokens層のコンポーネントでIons、Quarksなどのように名前がつけられるようです。

今回は色のことは置いておいて、先ほどのロジックのみを持ちデザイン拡張性を保持したいコンポーネントクラスに関してはAtomsに入れず、Ionsに入れることで、本来Atomsに入れたい「矩形の見た目を持ったボタンのコンポーネント」をAtomsに入れることができるのではないでしょうか。

まとめ

問題点
ロジックのみを持ちデザイン拡張性を保持したいコンポーネントクラスをAtomsに入れると、本来のAtomsがMoleculesに入ることになってしまい、チーム内で混乱を産む。

解決方法
Ions階層を取り入れ、ロジック担当のクラスはIonsに入れる。

Atomic Designは複数人で使う場合、どの層に入れるかが個人によって異なることが多いので、その問題を解決するためにAlt Atomic Designのようなものをいろんな人が考案しています。オレオレになりすぎるのは良くないですが、プロジェクトに合わせて拡張などをして使用することが、Atomic Designとの上手い付き合い方なのではないかと考えます。