Atomic Designの複雑さをカット！3段階で判断迷子を減らせた件
はじめに
Atomic Designは、効率的で再利用可能なUIコンポーネントの構築方法として人気を博しています。しかし、その多層構造に慣れるまで、多くの人が混乱し、どのタイミングでどのパーツを使うべきか悩むことがあります。Atoms、Molecules、Organisms、Templates、Pagesの5段階が用意されているのですが、この複雑さがかえって開発チームの判断を曖昧にしてしまうことも少なくありません。
そこで私が取り入れたのは、Atomic Designをシンプルに3段階にすることです。
結論
そこで、Atomic Designをシンプルに3段階に分けて考えるアプローチを紹介します
-
Parts(New!!)
- 機能として最小の単位であるコンポーネント。単一の機能や役割を持つ
- Templates
- 複数のPartsが組み合わさって、特定の機能を提供するコンポーネント。通常、独立して再利用される
- Pages
- TemplatesやPartsを組み合わせて、最終的なページ全体のレイアウトや機能を構成するコンポーネント
前提: Atomic Designとは
Atomic DesignはUIの構造を細かく分解し、再利用可能なコンポーネントを作成するための方法論です。最も小さな要素から、複雑なUIまで段階的に構築することで、デザインの一貫性を保ちながら、効率的な開発を可能にします。
引用元: Atomic Design Methodology
このコンポーネントどの階層になる？
AAtomic Designは、UIを階層化して整理するための強力なフレームワークですが、複数の機能を持つコンポーネントに対しては、その階層の境界が曖昧になりやすく、どのレベルに分類するかで意見が分かれることも。
ここでは、以下のようなTabsコンポーネントをどの階層に分類するべきか、異なる解釈を検討してみましょう(引用元: Chakra UI)。
これの汎用的なコンポーネントを作ってみました。
import React from 'react';
import { Tabs, TabList, Tab, TabPanels, TabPanel } from '@chakra-ui/react';
interface CustomTabsProps {
tabs: string[];
tabPanels: React.ReactNode[];
}
const CustomTabs: React.FC<CustomTabsProps> = ({ tabs, tabPanels }) => {
return (
<Tabs>
<TabList>
{tabs.map((tab, index) => (
<Tab key={index}>{tab}</Tab>
))}
</TabList>
<TabPanels>
{tabPanels.map((panelContent, index) => (
<TabPanel key={index}>
{panelContent}
</TabPanel>
))}
</TabPanels>
</Tabs>
);
};
export default CustomTabs;
このコンポーネントをAtomic Designのどの階層に分類するかは、開発チームやプロジェクトの方針に応じて異なります。それぞれの階層における考え方を見ていきましょう。
先ほどのタブコンポーネントの各階層の主張
上記のCustomTabsはどの階層になるか考えてみましょう
Atoms派
Atomsは、UIの最も基本的な構成要素であり、ボタンやアイコンなど、単一機能を持つ最小単位の要素として扱われます。Tabs コンポーネントをAtomsと見なす場合、次のような理由があります。
- 単一の機能を持つ要素として考える: このコンポーネントは単に「タブを切り替える」というシンプルな機能しか持たないため、最小単位としてのUI要素（Atoms）と見なすことができる
- 小さく再利用可能:
Tabsはページ内の小さなセクションで頻繁に使われるUIコンポーネントなので、他のAtomsと同様に扱うことが可能
Molecules派
Moleculesは複数のAtomsを組み合わせて機能を持つ、少し複雑な要素です。TabsをMoleculesと捉える場合、次のような意見があります。
- 複数の小さな要素の組み合わせ:
Tabsコンポーネントは、タブのリスト(TabList)とその中のタブ（Tab）、そしてそれに対応するパネル（TabPanels）を持っており、複数のAtomsが組み合わさっているため、Moleculesに分類されると考えられる - UIの一部としての機能: タブ切り替えは、UI全体に対して個別の一部を構成しており、他の要素と組み合わせて一つの機能を果たします。これにより、Moleculesとして十分な役割を持つと捉えることができる
Organisms派
Organismsは、複数のMoleculesやAtomsが集まって形成される大きなUIのブロックです。
Tabs コンポーネント全体をOrganismsと捉える場合、次のような意見があります。
- 独立したUIのセクション: このコンポーネントは、独立した大きなUIの一部であり、ページ内で重要な役割を果たします。タブ切り替えの機能は、それ自体が複数のAtomsやMoleculesを含むため、Organismsとして分類するのが適切だと考えられる
- 複数のコンポーネントの集合体: Tabs は、リスト、タブ、パネルといった複数の役割を果たすパーツを持つため、これらが組み合わさることで、複雑な機能を持つOrganismsに分類できると考えらる
Atomic Designを3段階にしてシンプルに考えてみる
Atomic Designの5段階（Atoms、Molecules、Organisms、Templates、Pages）は、UIの構造を細かく分類するために非常に有用ですが、時にはその複雑さが意思決定やコンポーネントの整理を難しくしてしまうことがあります。そこで、Atomic Designをシンプルに3段階に分けて考えるアプローチを紹介します。
-
Parts(New!!)
- 機能として最小の単位であるコンポーネント。単一の機能や役割を持つ
- Templates
- 複数のPartsが組み合わさって、特定の機能を提供するコンポーネント。通常、独立して再利用される
- Pages
- TemplatesやPartsを組み合わせて、最終的なページ全体のレイアウトや機能を構成するコンポーネント
先ほどのタブコンポーネントは3段階の中で階層になる?
上記の3段階に基づく場合、CustomTabsコンポーネントはPartsに分類されることが多いです。その理由は以下の通りです。簡単にいうとこれ以上分割して使うことないよねというコンポーネントに関してはPartsに当たります。
-
CustomTabsは「タブの切り替え」という単一の機能に特化しており、その機能自体がUI全体の中で特定の役割を果たすため、最小単位の部品として考えることができる -
TabListとTabPanelsは独立して使用されることがほとんどなく、これらは一緒に機能することを前提としているため
Partsを定義することにデメリット
Atomic Designを3段階に簡略化し、Partsとして最小の単位を定義するアプローチには多くのメリットがありますが、一方でデメリットもいくつか存在します。以下に主なデメリットを挙げ、それぞれについて解説します。
1. 細分化の限界が曖昧になる
Partsを導入することで、最小の単位としての定義を簡略化できますが、「これ以上分割しない」という判断基準がチームごとに異なるため、曖昧さが生まれることもあります。
例: CustomTabsのようなコンポーネントが、チームAではPartsとみなされる一方で、チームBでは「もっと細かく分割できる」として再構成されるケースが発生する。
2. 再利用性が限定される
Partsとして定義したコンポーネントは、その単一の役割に特化しているため、特定のユースケースに依存する可能性があります。結果として、別のプロジェクトや異なる文脈での再利用性低下することがあります。
例: CustomTabsコンポーネントが特定のデザインシステムに依存している場合、別のプロジェクトではそのまま使用できない
おわりに
Atomic Designを3段階にシンプル化することで、多くの場面で判断のスピードを上げ、コンポーネントの分類や開発プロセスの効率を向上させることができます。しかし、この方法にもデメリットが存在し、特にチームの規模やプロジェクトの性質によって適用性が変わる点に留意する必要があります。
3段階に簡略化することで得られるメリットと、特定の状況で発生するデメリットを天秤にかけながら、柔軟な運用を心がけることが成功への鍵となるでしょう。
最後までお読みいただき、ありがとうございました！
Discussion