Zenn
😊

Atomic Designが苦手な理由

2022/05/06に公開
React
デザイン
tech

Atom Designが苦手な理由

複数のClientProject(SPA,SSR)を経験して自分は、atomic designが苦手ということに気がついた(遅い)。言語化できていなかったので、とりあえず言語化しようと思った。

なんでAtomic Designに苦手意識があるのか？

個人的に、設計思想としてAtomicDesignは好きです。
Pages, Templates, Organisms, Molecules, Atomsで構成を分けて作成をすることは、
Viewを開発する場面においてテストも、各構成ごとに記述がしやすく_慣れれば_開発速度は上がっていると思う。

なんで好きなのに、苦手意識があるかというと、以下の3点においてAtomicDesignがチームで開発する上で辛くなった経験があるからです。

  1. Container層との連携したディレクトリ設計(HOCs化したりすればいいが。。。それをどこにおくか。)
  2. Atomic DesignでUIのディレクトリを設計しており、利用する側はどこにあるか考えないといけなくなる
  3. エンジニアへのオンボーディングコストがかかる

1. Container層との連携したディレクトリ設計

MoleculesやOrganisms以上のレイヤーには、データを取得したりするロジックが入るケースが多い。
以下のCustomHooks, Component, Containerがある程度結合しながらディレクトリ設計上別になるケースがあり、components/molecules/search-text.tsx, hooks/use-search-tasks.tsx, containers/search-tasks-containers.tsxになるケースがある。

// custom hooks
export function useSearchTasks() {
    const {data, error} = useSWR("/api/tasks")
    cost [ filteredTasks, setTasks ] = useRecoilState(searchedTaskList)
    return { loading, disabled, searchText }
}

// tsx
export function SearchText(props: {
    loading,
    disabled,
    searchText
}) {
   return (
       <FormControl>
	<Label />
	<Input />
	<Button type="submit" />
       </FormControl>
   )
}

// 呼び出し元
export function SearchTextContainer() {
  const data = useSearchText()
  return (<SearchText {...data}/>)
}

しんどいポイントは、

pages/tasks-page.tsx 
 |-> containers/search-tasks-container.tsx
         |-> hooks/use-search-tasks.tsx
         |-> components/molecules/search-text.tsx

などデータを取り扱うlayerなどディレクトリを跨ぐと心理的な負荷につながる(探すのめんどい) + テストがなかった場合は発狂する可能性がある(app/containersはapplication scope...)
また、AtomicDesignの経験が少ないメンバー以外は探すときに苦労しているのが見れる。。。

2. Atomic DesignでUIディレクトリを設計しており、利用する側はどこにあるか考えないといけなくなる

遭遇したのは下のディレクトリ構成。ここで立ち止まって、考えると、SearchTextFormを利用したいのにAtomicDesignを構成する要素から探さないと行けない。

個人的に、期待しているディレクトリ構成はmui/material-ui、vuetifyjs/vuetifyの慣習に倣った構成を期待していることが多い。

// 遭遇したディレクトリ設計
app/components
|- atoms
|- molecules
|- organisms
|- templates

//　期待したいディレクトリ構成
app/components
|- SearchTextForm

多分Export使えばいけるでって人いると思うけどprojectおおきくなると、IDEでもおうのに時間がかかることがおおいです。(それに加えて、namespaceかぶることを防止するために、XXX([.|-]atom.tsxとか利用する際に「いる？？？」ってつく名前が増える)

app/components
|- atoms
|- molecules
|- organisms
|- templates
|- index.tsx //ここでまるっとExport

3. エンジニアへのオンボーディングコストがかかる

これは結構辛くて、AtomicDesignになれいない人に参画してもらった場合や、そもそも作った構成で(orgnaisms, moleculesなど)の差異が言語化できていない場合(理解できるように)は小さい開発だけでも時間がとられてしまうことが多かった。
まぁ、いっかとおいといてごめんなさい:bow

ぐだぐだいったけど、お前はどうやって開発しているんか？

AtomicDesignは好きですが、ディレクトリの設計にAtomic Designを構成する要素を入れないように対応しています。
ですが、テストはPages -...-> Atoms -...-> Pagesのように流れでテストを記述しているようにしています。

app/components -> nrwlを使う時はlibに突っ込む
|- SearchText
|- Button
|- Table
app/user/components -> Scopeをuserのみに区切る SPAの場合はLazyできるようにdomainで区切る。
|- UserList
|- UserIcon

あくまで、自分が経験したものですので、こうやった方がいいなどあったら教えていただきたいです。

Discussion