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

Atomic Design周りについての私見

ponday
November 29, 2018

Atomic Design周りについての私見

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

ponday

November 29, 2018
Tweet

More Decks by ponday

Other Decks in Programming

Transcript

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

    View Slide

  2. Profile
    - ponday (Honda, Yusuke)
    - 株式会社ベガコーポレーション エンジニア
    - Like : TypeScript / Elixir / Python etc…
    - 日曜フロントエンドエンジニア
    - 副業もやってます

    View Slide

  3. #think_atomic_design

    View Slide

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

    View Slide

  5. View Slide

  6. 詳しくは Webで

    View Slide

  7. 理屈はかんたん

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  11. なぜ?

    View Slide

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

    View Slide

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

    View Slide

  14. Atomic Design がもたらしたもの
    - コンポーネント指向ベースのデザインシステム
    - ページ → 部品ではなく部品 → ページな考え方
    - エンジニアとデザイナの共通言語
    - ページを構成するコンポーネント階層の体系付け
    - 階層ごとの命名

    View Slide

  15. Atomic Design が考慮しないもの
    - CSS設計
    - ロジックを分割する境界
    - デザイン的な境界とプログラム的な境界は違うはず
    - データの受け渡し
    - コンポーネントのプロパティ
    - 状態管理

    View Slide

  16. アプリケーション開発に適用するには +α が必要

    View Slide

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

    View Slide

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

    View Slide

  19. 基本戦略

    View Slide

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

    View Slide

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

    View Slide

  22. TemplatesとPages
    - PagesはTemplatesに具体的なデータが入ったもの
    - つまりPages = 最終的なレンダリング結果
    - コンポーネントはTemplatesまで作れば良い
    - UIテスト用にPagesを定義するという手も

    View Slide

  23. コンポーネントの管理

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  29. コンポーネント間の依存関係
    Atoms
    Molecules
    Organisms
    Templates
    依存するもの
    なし
    Atoms
    Atoms
    Molecules
    Organisms
    Organisms
    依存の数
    0
    2つ以上
    1つ以上
    1つ以上
    ここは無理に
    制限しない

    View Slide

  30. データの受け渡し

    View Slide

  31. Organisms Molecules Atoms
    Templates
    props props props
    event event event
    『プロパティを渡して、イベントを受け取る』が原則

    View Slide

  32. データの受け渡し
    - 親→子はプロパティ
    - 親は自分が受け取ったプロパティを、子に適切に振り分ける
    - Templates→Atomsでプロパティのサイズは小さくなるはず
    - 子→親はイベントハンドリング
    - 状態管理まわりなど、一部例外あり(後述)

    View Slide

  33. 状態管理

    View Slide

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

    View Slide

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

    View Slide

  36. Organisms Molecules Atoms
    Templates
    props props props
    event event event
    Store
    (subscribe)
    /dispatch
    subscribe
    / dispatch
    アプリケーション固有のロジックは
    Templates、Organismsで処理
    → Storeもアプリケーション固有

    View Slide

  37. 状態管理
    Atoms
    Molecules
    Organisms
    Templates
    dispatch
    -
    -


    subscribe
    -
    -


    View Slide

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


    subscribe
    -
    -


    ※このあたりはプロジェクトの特性による

    View Slide

  39. まとめ
    - Atomic DesignはあくまでUIデザインの手法
    - そのままアプリケーション開発に使うとつらい
    - 制約が強い
    - そもそもプログラムとしての実装が考慮されていない
    - アプリケーション開発のためには+αの設計が必要
    - 考えないといけないことは結構多い

    View Slide

  40. アプリケーション開発も考慮に入れた
    Alt Atomic Designの登場を待つのも手では?

    View Slide

  41. Thank you !!

    View Slide