アトミックデザインをやめて、ディレクト構造を見直す
Category:
最終更新日
2023/03/05 12:50
この記事の目次
atma株式会社では、週2回、フロントエンド・バックエンドに分けて勉強会をしています。
今回は、フロントエンド勉強会で発表した、「アトミックデザインからの脱却」をこちらでも公開します。
そもそもアトミックデザインって何
アトミックデザインとは、Brad Frostさんが提唱した、フロントエンドのコンポーネント設計についてのデザインシステムです。
Brad Frostさんがアトミックデザインについて提唱している記事
大抵のアトミックデザインの解説では以下の画像が使われています。
Brad Frostさんの記事で紹介のため使われている画像なので、多くの方に使われているようですね。
出典: https://bradfrost.com/blog/post/atomic-web-design/
アトミックデザインについて要約すると、
デザインシステムを考えに考え、考えぬいたら、化学に行き着いた。
UIも地球上に存在するすべての物質のように、原子、分子、有機体、、のようにできてるのでは？？
というような感じです。
実際の現場では、コンポーネントを5つのディレクトリに分けることで、採用されていることが多いと思います。
- atoms
- molecules
- organisms
- templates
- pages
Brad Frostさんも言っている通り、templates, pagesは、化学的ではないですが便宜上便利なので入れているらしいです。
なんでアトミックデザイン使うの？
これは、調べても僕の力では見つけられなかったです。
https://design.dena.com/design/atomic-design-を分かったつもりになる
有名な記事はいくつかあるのですが、これといった決定打はないようです。
「アトミックデザイン最近（2018~）はやってる」
「アトミックデザイン便利そう」
みたいな感じかなと思っています。
アトミックデザイン本当に便利？？
ここからが、今日話したいことになります。
結論を述べると僕は、アトミックデザインが非常に分かりづらいものだと思っています。
前職で大きなプロジェクトで1回、社内では2回利用しています。
何が分かりづらい？？
1. そもそもatomicとかmoleculesとかパッと見よくわからない
シンプルに馴染みのない単語ですし、何を指しているのか分かりづらいです。
moleculesとorganismsとかほぼ違いが分からないです。
また、moleculesとorganismsの範囲が案件によってかなり違います。
デザインにおける共通言語としては、atomicsしか定着してないと勝手に思ってます。
2. そもそも、何でもかんでも共通化できるものではない
アトミックデザインを採用すると、原則として、必ず、atomic・molecules・organismsのいずれかのディレクトリにコンポーネントを作らいないと行けないです。
例えば、お問い合わせフォームのコンポーネントを考えると、フィールドはatomicとわかります。
では、フィールドの結合は？submit処理はどこに？エラー処理はどこに？
採用するフレームワークによっては、完全に分離ができないこともあります。
実装によっては、ほとんどがpagesに入ってしまい、pagesが肥大化してしまう可能性もあります。
3. pagesの肥大化を恐れて、コンテキスト込のorganismsが増える
上記とも被りますが、特定のページでしか使わないけど、共通化も面倒なとき、一旦organismsに
orgnisms/contact/contactForm.tsx (.vue)
のようになったりしがちです。
まとめると
アトミックデザインという、デザインシステムを維持するのは、かなり難しいのと、そのコストが高いと思っています。
もちろん、しっかりと定義がされたアトミックデザインは、強いと思いますし素晴らしいと思うのですが、僕の感覚では、上記3点の理由であまりそうならないと思っています。
じゃあ、どんな構造でコンポーネントを設計していけばいいの？
いくつかのタイミングで、紹介していますが、僕は以下の記事の考え方がアトミックデザインからの脱却のための近道だと思っています。
Atomic Designをやめてディレクトリ構造を見直した話｜食べログ フロントエンドエンジニアブログ
食べログの解決策は？
食べログでは、アトミックデザインの解決策をディレクトリ構造に見出し、改めてどのようにコンポーネントを切り替えるのかを定義したようです。
食べログが提示した、ディレクトリ構造は以下のとおりです
├── app
│ ├── entrypoints # 1
│ │ └── [Rails Subsystem Name]
│ │ └── [Rails Controller Name]
│ │ └── [Rails Action Name].tsx
│ ├── components
│ │ ├── pages
│ │ │ └── [PageName]
│ │ │ ├── index.tsx # 2
│ │ │ ├── index.test.tsx
│ │ │ ├── hooks.test.tsx
│ │ │ ├── hooks.ts
│ │ │ ├── presenter.test.tsx
│ │ │ ├── presenter.tsx
│ │ │ ├── portals/ # 3
│ │ │ └── [Component Name]/ # 4
│ │ ├── projects # 5
│ │ └── uiParts # 6
│ │ ├── [Component Name]
│ │ │ ├── index.stories.tsx
│ │ │ ├── index.tsx
│ │ │ ├── presenter.test-d.tsx
│ │ │ ├── presenter.test.tsx
│ │ │ ├── presenter.tsx
│ │ │ └── style.tsx
│ ├── contexts
│ ├── ducks
│ ├── hooks
│ ├── styles
│ ├── types
│ └── utils
食べログの構成の何がいいの？？
1. コンポーネントをファイルではなく、ディレクトリで見る！
非常に利益の大きいコンポーネントの切り方です。
component_name/index.tsx(index.vue) とすることで、ディレクトリ内に、そのコンポーネントでしか使わない処理等を入れ込んでいくことができます。
2. AtomicsがUIpartsに
名前がとてもわかり易いと思いました。特にatomic性よりも、UIの範囲しか持たないという点がわかり易いと思います。
UIのためであれば多少大きいコンポーネントでも良いということです。コンポーネントの大きさで、atomicに入れるか入れないべきか悩むことがなくなります。
3. pagesに入れられるコンポーネントが増える
これまでは、正直このページでしか使えないな、、というようなコンポーネントもorganisms等に入れていたりすることもあると思います。
そんなコンポーネントは、そのページのコンポーネントとして入れてしまいましょう。
atmaや僕だったらどう採用する？
僕は、atmaや自分の持っているプロジェクトではこうしたいな、、という構成を以下のようにまとめました。
├── app
│ ├── components
│ │ ├── pages
│ │ │ └── [PageName]
│ │ │ ├── index.tsx
│ │ │ └── [Component Name]/
│ │ ├── contents【TBD】 このディレクトリの名前が定まらない、、common? contents?
│ │ ├── layouts
│ │ │ ├── [layoutPartsConponent].tsx
│ │ │ └── [Layout Name]
│ │ │ ├── index.tsx
│ │ │ └── [Component Name]/
│ │ └── uiParts
│ │ ├── [Component Name]
│ │ │ ├── index.tsx
│ ├── contexts
│ ├── hooks
│ ├── types
│ └── utils
1. layoutsディレクトリを置きました。
アトミックデザインで言うところの、templatesみたいなポジションのものです。
基本的には、一つのレイアウトのことが多いと思いますが、LP、お問い合わせページ、トップページ等、ナビゲーションは共通だが、ページの構成が違うパターンがあったりします。
そんなときに使えればと思っています。
また、ナビゲーションバー、ヘッダー、フッター等、共通の場合は、layoutsの直下にファイルかディレクトリで入れれば良いと思います。
2. projects を contentsに変更
projectsが直感的ではないので、一旦contentsとして自分のプロジェクト（個人的な）ではやってみています。
contents以外の共通コンポーネントは大方、layoutsでやれているので、今のところ問題なしです。
3. 方針の変更
構造からは見えないのですが、僕の考える方針では、すべてのコンポーネントをディレクトリとして切る必要はないと思っています。
単純なコンポーネントであれば、直接 componentName.tsx(componentName.vue)でも良いと思います。
まとめ
なんとなく、アトミックデザインを使用する安心感みたいなものがあると僕は思っています。
ただ、それ以外のデザイン設計にも目を通してみて、より良いものを選んでいければいいなと思いました。
Tags:
実際に利用していておすすめのサービス
