はじめに
ゆとり世代の中野です。
さっそくチャレンジについて書いていきます。
チャレンジする背景
- Atomic Designを導入して失敗してきた記録を残しておく
- ある程度いい感じにComponentの粒度を定義できたので残しておく
チャレンジ内容
- 考えを整理する
Atomic Designで失敗したこと
深く考えずに導入したこと
- 考え方はすごくシンプルでわかりやすいので深く考えずに導入できてしまうことでいくつもの弊害を生んでしまいAtomic Design難しいになった
- applicationの場合はDesign+Logicになるため複雑化した
- さらに複雑性が入ってくるとデザイナとエンジニアの協業のハードルが上がる
- 人によってComponentの粒度に対する認識が違うため作る人によって成果物が異なる
UIフレームワークのパーツをatomと定義したこと
- UIフレームワークの1つ1つのmoduleをatomと定義した
- 粒度がProductではなくUIフレームワークに依存してしまう
- あくまで粒度自体はProductで定義すべきもの
atomですべてのパターンを作ったこと
- すべてのパターンを作った
- 外からpropsを渡せるようにするべきでした
moleclues配下をフラットにしすぎたこと
- atomsと同じくmoleculesも再利用性できるため同じようにしたこと
- 組み合わせ使うという特性があるためatomと同じような構成にするには無理がある
- 必ずどこかでそれらの歪を吸収するところが出てくる
organizationsがmoleculesを組み立てる場所になっていたこと
- molecluesを再利用性しやすいように汎用的に作っていたのでここでComponentの組み立てを行っていました
- organizationはmoleculesを組み立てる場所ではなさそうです
organizationsがmoleculesの差別化があいまいだった
- 何がorganizationでmoleculesなのか定義があいまいで多くの混乱を生みました
- Atomic Designで特に難しいのはorganizationがmoleculesの切り分けでした
どうすればよかったのか
各レイヤーの定義を明確にする
- Componentには限定的Componentと汎用的Componentがあることを理解する
- 限定的Componentまで汎用的Componentに含めることで複雑性がマシマシになる
- この2つのComponentの存在を理解することで一気に設計難易度が下がった
各レイヤーの定義を決める
- 今開発しているProductでは以下のように明確に決めています
レイヤー | 定義 |
Pages | 関心事はページのコンテキスト
Templateを組み込み動的なページにする |
Templates | 関心事はレイアウト
Logicは一切持たない |
Organizations | 関心事はドメインロジック
molecuesのUI+ドメインロジックを使い固有のUI/UXを提供する |
Molecules | 関心事はUIComponentのLogic
moleculesだけでUI(Mock)が実現ができる |
Atoms | Productの中でこれ以上分解することができないComponent |
- 特にOrganizationsとMoleculesを関心事で分離することであいまいだった両者が明確に別物として認知できるようになりました
結論
なぜAtomic Designは難しいのか
- 概念のため具体的な方法論ではないため
- 人によって考え方が違うため共通の認識を作るのが難しい
なぜAtomic Designで失敗するのか
- 基本的な考え方はシンプルなので導入しやすい
- Logicが加わると難易度が急にあがる
- 明確な定義やルールがなくてもふんわりはじめられる
どうすればAtomic Designと仲良くなれるのか
- 導入時に明確に定義する
- 再定義し作り直す
- リファクタする
さいごに
- 現時点では一番納得できる定義が行えたと思っていますが今後もっといい方法がわかればUpdateします
- この記事にもっと早く出会えていればこんなに苦しむこともなかった気がする
yutanakano
WEBエンジニア
大阪生まれのゆとり世代です
趣味はバイクでツーリングに行くこと
愛車は Ninja ZX-25R SE KRT EDITION
Expoでプロダクトを作っています
