Atomic Designが苦手な理由
Atom Designが苦手な理由
複数のClientProject(SPA,SSR)を経験して自分は、atomic designが苦手ということに気がついた(遅い)。言語化できていなかったので、とりあえず言語化しようと思った。
なんでAtomic Designに苦手意識があるのか?
個人的に、設計思想としてAtomicDesignは好きです。
Pages, Templates, Organisms, Molecules, Atomsで構成を分けて作成をすることは、
Viewを開発する場面においてテストも、各構成ごとに記述がしやすく_慣れれば_開発速度は上がっていると思う。
なんで好きなのに、苦手意識があるかというと、以下の3点においてAtomicDesignがチームで開発する上で辛くなった経験があるからです。
- Container層との連携したディレクトリ設計(HOCs化したりすればいいが。。。それをどこにおくか。)
- Atomic DesignでUIのディレクトリを設計しており、利用する側はどこにあるか考えないといけなくなる
- エンジニアへのオンボーディングコストがかかる
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
あくまで、自分が経験したものですので、こうやった方がいいなどあったら教えていただきたいです。
Author And Source
この問題について(Atomic Designが苦手な理由), 我々は、より多くの情報をここで見つけました https://zenn.dev/gama/articles/8cc08363c0016d著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Collection and Share based on the CC protocol