Atomic Design周りについての私見

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

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