Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Atomic Design周りについての私見

52604f94a6d2172df2cad5ab45189940?s=47 ponday
November 29, 2018

Atomic Design周りについての私見

ITのむずかしいを簡単にする会 - LT会 #5(2018/11/29)の発表資料です。

52604f94a6d2172df2cad5ab45189940?s=128

ponday

November 29, 2018
Tweet

Transcript

  1. Atomic Design周りについての私見 ITのむずかしいを簡単にする会 - LT会 #5 / Nov 29th, 2018

    ponday (@ponday_dev)
  2. Profile - ponday (Honda, Yusuke) - 株式会社ベガコーポレーション エンジニア - Like

    : TypeScript / Elixir / Python etc… - 日曜フロントエンドエンジニア - 副業もやってます
  3. #think_atomic_design

  4. Atomic Design ? - UIデザイン手法の一つ - コンポーネントを原子、分子に見立てる - ページ単位ではなく、コンポーネント単位で考える -

    小さいコンポーネントの組み合わせでページを表現
  5. None
  6. 詳しくは Webで

  7. 理屈はかんたん

  8. しかし、実際に適用してみると......

  9. このコンポーネントは Atoms? Molecules? CSSってどう分けるべき? コード量が増えてつらい...... 状態はどこでどう管理すれば良いんだろう?

  10. どうもやりづらい......

  11. なぜ?

  12. Atomic Design ≠ アプリケーションの 設計手法

  13. Atomic Design = UIデザインの手法

  14. Atomic Design がもたらしたもの - コンポーネント指向ベースのデザインシステム - ページ → 部品ではなく部品 →

    ページな考え方 - エンジニアとデザイナの共通言語 - ページを構成するコンポーネント階層の体系付け - 階層ごとの命名
  15. Atomic Design が考慮しないもの - CSS設計 - ロジックを分割する境界 - デザイン的な境界とプログラム的な境界は違うはず -

    データの受け渡し - コンポーネントのプロパティ - 状態管理
  16. アプリケーション開発に適用するには +α が必要

  17. +αで検討が必要なもの - コンポーネントの管理 - コンポーネント間の依存関係 - コンポーネント間のデータの受け渡し - 状態管理

  18. ※ ここからは完全に個人的見解

  19. 基本戦略

  20. コンポーネントの役割 Atoms Molecules Organisms Templates 役割 汎用的な部品 汎用的な部品 アプリケーション固有の部品 ページのレイアウトなど

  21. 基本戦略 - Atoms、Moleculesは汎用的にする - 他プロジェクトでの再利用性も考慮 - 依存関係をシンプルに保つ - UIライブラリとして提供するのはこのあたりまで -

    Organisms以上はそのアプリケーション固有の層 - 基本的にそのアプリケーションの外では再利用しない
  22. TemplatesとPages - PagesはTemplatesに具体的なデータが入ったもの - つまりPages = 最終的なレンダリング結果 - コンポーネントはTemplatesまで作れば良い -

    UIテスト用にPagesを定義するという手も
  23. コンポーネントの管理

  24. コンポーネントの管理 - そのままではコンポーネントの重複は免れない - Storybookなどの導入は事実上必須

  25. コンポーネント間の依存関係

  26. 厳密に言えば、あるコンポーネントは 一つ下レイヤーのコンポーネントのみに依存する

  27. ただし現実的には、この制約は結構つらい

  28. コンポーネント間の依存関係 Atoms Molecules Organisms Templates 依存するもの なし Atoms Atoms Molecules

    Organisms Organisms 依存の数 0 2つ以上 1つ以上 1つ以上
  29. コンポーネント間の依存関係 Atoms Molecules Organisms Templates 依存するもの なし Atoms Atoms Molecules

    Organisms Organisms 依存の数 0 2つ以上 1つ以上 1つ以上 ここは無理に 制限しない
  30. データの受け渡し

  31. Organisms Molecules Atoms Templates props props props event event event

    『プロパティを渡して、イベントを受け取る』が原則
  32. データの受け渡し - 親→子はプロパティ - 親は自分が受け取ったプロパティを、子に適切に振り分ける - Templates→Atomsでプロパティのサイズは小さくなるはず - 子→親はイベントハンドリング -

    状態管理まわりなど、一部例外あり(後述)
  33. 状態管理

  34. Organisms Molecules Atoms Templates props props props event event event

    Store subscribe / dispatch (subscribe) /dispatch
  35. Organisms Molecules Atoms Templates props props props event event event

    Store subscribe / dispatch ここは汎用的に保ちたい → Storeにはアクセスしない (subscribe) /dispatch
  36. Organisms Molecules Atoms Templates props props props event event event

    Store (subscribe) /dispatch subscribe / dispatch アプリケーション固有のロジックは Templates、Organismsで処理 → Storeもアプリケーション固有
  37. 状態管理 Atoms Molecules Organisms Templates dispatch - - ◦ ◦

    subscribe - - △ ◦
  38. 状態管理 Atoms Molecules Organisms Templates dispatch - - ◦ ◦

    subscribe - - △ ◦ ※このあたりはプロジェクトの特性による
  39. まとめ - Atomic DesignはあくまでUIデザインの手法 - そのままアプリケーション開発に使うとつらい - 制約が強い - そもそもプログラムとしての実装が考慮されていない

    - アプリケーション開発のためには+αの設計が必要 - 考えないといけないことは結構多い
  40. アプリケーション開発も考慮に入れた Alt Atomic Designの登場を待つのも手では?

  41. Thank you !!