Open1
Atomic Designを使わない理由
ピン留めされたアイテム
mk668a目的のコンポーネントが見つけづらい、検索性が下がる
- 5つの構成要素に分類する時、分類方法を独自に定義する必要があります。そのため、例えばButtonコンポーネントを探す際に５つの構成要素の中のどこに分類されているかを分類方法から推測して探す必要があります。
分類を考えるのが難しい
- 5つの構成要素の分類方法やそれぞれの要素のロジックの責務についてのルールを定義しなければならなく、定義を共有するだけでもコストがかかります。また、コンポーネントの過度な分類は新規参入者のキャッチアップのコストを高くします。
- 特に、AtomsとMolecules、TemplatesとPagesに分類が難しくお互いのコンポーネントが混在しやすくなります。また、多くのコンポーネントがOrganismsになってしまい、Organismsだけが肥大化してしまうケースが多いです。
- 上述の通り、５つの構成要素の分類が難しいのはそもそも分類が多すぎることにも問題があります。実際はAtomsとMolecules、TemplatesとPagesを統合して一つの分類としても問題が無く、その方がシンプルで使いやすくなる場合があります。
ページに依存したコンポーネントができる
- 実際のUIでは、一つのページでしか使わないコンポーネントが出てきて、そのコンポーネントはOrganismsになる場合が多いです。これはOrganismsが肥大化することに繋がります。また、特定のページでしか使わないコンポーネントをOrganismsに含めてしまうことに違和感があります。実際の開発では、特定のページでしか使われないコンポーネントは、該当のページのディレクトリ内に配置するのがいいと思います。
atomを変更した時に、他のコンポーネントに依存するため調整が必要になる
- Atomic Designでは最小単位の要素がatomになり、他の構成要素はatomを組み合わせて作成するためatomのUIを変更すると他のコンポーネントのUIも変更されることになります。これはメリットでもありますが、綿密に設計しない限り、依存する他のコンポーネントのUIを調整する必要が出てきます。
- atomから作らなくてもスタイルガイドをベースに作れば、統一感のあるUIになるため最小単位の要素からコンポーネントを作成していく必要はないと考えます。また、atomから作成していくのは必要なコンポーネントが出てきた場合にatomから辿ってUIを考える必要があり、atomに足りないコンポーネントがあれば新たなコンポーネントを作らなければなりません。この際に整合性が取れるように全体のコンポーネントを見て考え直さなければいけない場合が出来てます。
AtomicDesignとReactやVueなどのフレームワークとの相性があまり良くない
- AtomicDesignにはchildrenやpropsの考え方が合いません。
- AtomicDesignでは、例えばCardListというコンポーネントがあり、その中でCardというコンポーネントを使う場合、Cardに直接marginを持たせずにCardをliでラップしてそこにスタイルを当てるようなやり方になります。そのため、propsでclassを当てる等のやり方はAtomicDesignの考えに反します。
- また、AtomicDesignではchildrenを使わないシステムが採用されているが、ReactやVueではchildrenを使った方が綺麗に実装できる場合が多いです。