かつてAtomic Designの考え方と利点・欠点という記事を書きました。 この記事内で日本ではAbemaTVで使われていると書きました。そして今でもAbemaTVではAtomic Designの考えに基づいてコンポーネントが作られています。
AbemaTVでの経験を通じて、Webアプリケーションのクライアントサイドの開発者という立場からAtomic Designはどうなのかについて書いていきます。
なおAbemaTVではビューライブラリとしてReactを使っているので、React前提の話になります。
Atomic Designに基づくのは実際どうなのか
基本的には良いです。良い点について書いていたらAtomic Design を実案件に導入 - UI コンポーネントの粒度を明確化した結果と副産物 | ygoto3.comやAtomic Design powered by React @ AbemaTVに書いてある内容と似てきたので、良い点についてはこれらの資料を見てください。
ただし問題点もあります。いま思いつく限りでは大きく2つ問題があると考えています。
人によってコンポーネントの粒度が違う
Atomic Designにおいて atoms はそれ単体で使うことはなく molecules や organisms 内に取り込まれた状態で使われます。
また molecules にあたるコンポーネントは単一責任の原則に基づくのが良いとされています。
しかしコンポーネントによっては props が多すぎるものもあります。特に molecules の一部コンポーネントは props が22個あります。
実際に該当のコンポーネントは挙動を変更する理由がいくつかある状態です。
この場合は責務ごとにコンポーネントを分割すればよかったのかもしれません。 もしくはHigher-Order Components - Reactを取り入れても良いかもしれません。
デザイナーとデベロッパーのコンポーネントの粒度も違う
今だとデザイナーがSketchのSymbol上に構築したコンポーネントの粒度とデベロッパーが実装したコンポーネントの粒度が違うものもあります。
デザイナーとデベロッパーのどちらかの考えに粒度を合わせるのが良いでしょう。 この場合、基本的にはデザイナーの考えに合わせたほうが良いと思います。 morishitterのCSSの書き方（2016年夏） - morishitter blogにもある「デザインの意図を正確に理解した上で書かれたCSSは破綻しない」です。
とはいえ、自分もあまり余裕がなかったため「なぜこのデザインなのか」をあまり聞けていません（Slack上でどのデザインにするかやりとりしているときに「これが良いですねー」とか反応するくらい）。
Pattern Labのデモに作りたいコンポーネントのカテゴリーがあったらお互いそれに沿うようにするのもいいでしょう。
たとえば blocks だったら molecules で sections だったら organisms という感じです。
コンポーネントのテストが面倒
コンポーネントのテストを書く場合は enzyme を使って find() などを用いて要素があるかを探し、表示されている文字が期待のものと合致しているかなどをテストすると思います。
この場合テストとは直接的に関係ないコードがテストコード内に存在することになります。
テストを書くときにVirtual DOM内をいちいち探索しないといけなくなるため、そこまでテストコードが書かれていないコンポーネントが増えることにもなります。
また各コンポーネントがどのような props を持っているか調べないといけないため特に organisms にあたるコンポーネントのテストは面倒になるでしょう。
そのためJestのSnapshot Testingのように、スナップショットとなるコードを書いてテストコード側でそれと合致するか確かめるようにする流れができつつあります。
この記事はAbemaTV Advent Calendar 2017の17日目の記事でした。 AbemaTVではAtomic Designのよりよい運用を考えたいデベロッパーを募集中です。