ITのむずかしいを簡単にする会 - LT会 #5(2018/11/29)の発表資料です。
Atomic Design周りについての私見ITのむずかしいを簡単にする会 - LT会 #5 / Nov 29th, 2018 ponday (@ponday_dev)
View Slide
Profile- ponday (Honda, Yusuke)- 株式会社ベガコーポレーション エンジニア- Like : TypeScript / Elixir / Python etc…- 日曜フロントエンドエンジニア- 副業もやってます
#think_atomic_design
Atomic Design ?- UIデザイン手法の一つ- コンポーネントを原子、分子に見立てる- ページ単位ではなく、コンポーネント単位で考える- 小さいコンポーネントの組み合わせでページを表現
詳しくは Webで
理屈はかんたん
しかし、実際に適用してみると......
このコンポーネントはAtoms? Molecules?CSSってどう分けるべき?コード量が増えてつらい......状態はどこでどう管理すれば良いんだろう?
どうもやりづらい......
なぜ?
Atomic Design ≠アプリケーションの設計手法
Atomic Design = UIデザインの手法
Atomic Design がもたらしたもの- コンポーネント指向ベースのデザインシステム- ページ → 部品ではなく部品 → ページな考え方- エンジニアとデザイナの共通言語- ページを構成するコンポーネント階層の体系付け- 階層ごとの命名
Atomic Design が考慮しないもの- CSS設計- ロジックを分割する境界- デザイン的な境界とプログラム的な境界は違うはず- データの受け渡し- コンポーネントのプロパティ- 状態管理
アプリケーション開発に適用するには +α が必要
+αで検討が必要なもの- コンポーネントの管理- コンポーネント間の依存関係- コンポーネント間のデータの受け渡し- 状態管理
※ ここからは完全に個人的見解
基本戦略
コンポーネントの役割AtomsMoleculesOrganismsTemplates役割汎用的な部品汎用的な部品アプリケーション固有の部品ページのレイアウトなど
基本戦略- Atoms、Moleculesは汎用的にする- 他プロジェクトでの再利用性も考慮- 依存関係をシンプルに保つ- UIライブラリとして提供するのはこのあたりまで- Organisms以上はそのアプリケーション固有の層- 基本的にそのアプリケーションの外では再利用しない
TemplatesとPages- PagesはTemplatesに具体的なデータが入ったもの- つまりPages = 最終的なレンダリング結果- コンポーネントはTemplatesまで作れば良い- UIテスト用にPagesを定義するという手も
コンポーネントの管理
コンポーネントの管理- そのままではコンポーネントの重複は免れない- Storybookなどの導入は事実上必須
コンポーネント間の依存関係
厳密に言えば、あるコンポーネントは一つ下レイヤーのコンポーネントのみに依存する
ただし現実的には、この制約は結構つらい
コンポーネント間の依存関係AtomsMoleculesOrganismsTemplates依存するものなしAtomsAtomsMoleculesOrganismsOrganisms依存の数02つ以上1つ以上1つ以上
コンポーネント間の依存関係AtomsMoleculesOrganismsTemplates依存するものなしAtomsAtomsMoleculesOrganismsOrganisms依存の数02つ以上1つ以上1つ以上ここは無理に制限しない
データの受け渡し
Organisms Molecules AtomsTemplatesprops props propsevent event event『プロパティを渡して、イベントを受け取る』が原則
データの受け渡し- 親→子はプロパティ- 親は自分が受け取ったプロパティを、子に適切に振り分ける- Templates→Atomsでプロパティのサイズは小さくなるはず- 子→親はイベントハンドリング- 状態管理まわりなど、一部例外あり(後述)
状態管理
Organisms Molecules AtomsTemplatesprops props propsevent event eventStoresubscribe/ dispatch(subscribe)/dispatch
Organisms Molecules AtomsTemplatesprops props propsevent event eventStoresubscribe/ dispatchここは汎用的に保ちたい→ Storeにはアクセスしない(subscribe)/dispatch
Organisms Molecules AtomsTemplatesprops props propsevent event eventStore(subscribe)/dispatchsubscribe/ dispatchアプリケーション固有のロジックはTemplates、Organismsで処理→ Storeもアプリケーション固有
状態管理AtomsMoleculesOrganismsTemplatesdispatch--○○subscribe--△○
状態管理AtomsMoleculesOrganismsTemplatesdispatch--○○subscribe--△○※このあたりはプロジェクトの特性による
まとめ- Atomic DesignはあくまでUIデザインの手法- そのままアプリケーション開発に使うとつらい- 制約が強い- そもそもプログラムとしての実装が考慮されていない- アプリケーション開発のためには+αの設計が必要- 考えないといけないことは結構多い
アプリケーション開発も考慮に入れたAlt Atomic Designの登場を待つのも手では?
Thank you !!