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