Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Atomic Design周りについての私見
Search
ponday
November 29, 2018
Programming
1
730
Atomic Design周りについての私見
ITのむずかしいを簡単にする会 - LT会 #5(2018/11/29)の発表資料です。
ponday
November 29, 2018
Tweet
Share
More Decks by ponday
See All by ponday
関数型でGoFのデザインパターンやってみる
honda
1
1.3k
TypeScriptの型表現
honda
10
3.1k
Web Componentsの今
honda
1
430
これまでのReact、これからのReact
honda
0
320
Gatsbyお試し
honda
0
120
styled-components or emotion?
honda
0
690
Web ComponentsとAngular
honda
0
130
え、まだWeb Componentsを未来の技術だと思ってるの?
honda
2
840
Web Componentsの動向とPolymer
honda
4
2.6k
Other Decks in Programming
See All in Programming
One Enishi After Another
snoozer05
PRO
0
160
3年ぶりにコードを書いた元CTOが Claude Codeと30分でMVPを作った話
maikokojima
0
650
コードとあなたと私の距離 / The Distance Between Code, You, and I
hiro_y
0
190
Cursorハンズオン実践!
eltociear
2
1.2k
技術的負債の正体を知って向き合う
irof
0
260
Software Architecture
hschwentner
6
2.3k
What's new in Spring Modulith?
olivergierke
1
170
CSC305 Lecture 10
javiergs
PRO
0
260
理論と実務のギャップを超える
eycjur
0
180
Reactive Thinking with Signals and the Resource API
manfredsteyer
PRO
0
110
iOSでSVG画像を扱う
kishikawakatsumi
0
170
CSC305 Lecture 08
javiergs
PRO
0
280
Featured
See All Featured
Thoughts on Productivity
jonyablonski
70
4.9k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
508
140k
How to train your dragon (web standard)
notwaldorf
97
6.3k
Building Applications with DynamoDB
mza
96
6.7k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
10
620
Building a Scalable Design System with Sketch
lauravandoore
463
33k
Six Lessons from altMBA
skipperchong
29
4k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
jQuery: Nuts, Bolts and Bling
dougneiner
65
7.9k
The Power of CSS Pseudo Elements
geoffreycrofte
80
6k
Building an army of robots
kneath
305
46k
Designing Experiences People Love
moore
142
24k
Transcript
Atomic Design周りについての私見 ITのむずかしいを簡単にする会 - LT会 #5 / Nov 29th, 2018
ponday (@ponday_dev)
Profile - ponday (Honda, Yusuke) - 株式会社ベガコーポレーション エンジニア - Like
: TypeScript / Elixir / Python etc… - 日曜フロントエンドエンジニア - 副業もやってます
#think_atomic_design
Atomic Design ? - UIデザイン手法の一つ - コンポーネントを原子、分子に見立てる - ページ単位ではなく、コンポーネント単位で考える -
小さいコンポーネントの組み合わせでページを表現
None
詳しくは Webで
理屈はかんたん
しかし、実際に適用してみると......
このコンポーネントは Atoms? Molecules? CSSってどう分けるべき? コード量が増えてつらい...... 状態はどこでどう管理すれば良いんだろう?
どうもやりづらい......
なぜ?
Atomic Design ≠ アプリケーションの 設計手法
Atomic Design = UIデザインの手法
Atomic Design がもたらしたもの - コンポーネント指向ベースのデザインシステム - ページ → 部品ではなく部品 →
ページな考え方 - エンジニアとデザイナの共通言語 - ページを構成するコンポーネント階層の体系付け - 階層ごとの命名
Atomic Design が考慮しないもの - CSS設計 - ロジックを分割する境界 - デザイン的な境界とプログラム的な境界は違うはず -
データの受け渡し - コンポーネントのプロパティ - 状態管理
アプリケーション開発に適用するには +α が必要
+αで検討が必要なもの - コンポーネントの管理 - コンポーネント間の依存関係 - コンポーネント間のデータの受け渡し - 状態管理
※ ここからは完全に個人的見解
基本戦略
コンポーネントの役割 Atoms Molecules Organisms Templates 役割 汎用的な部品 汎用的な部品 アプリケーション固有の部品 ページのレイアウトなど
基本戦略 - Atoms、Moleculesは汎用的にする - 他プロジェクトでの再利用性も考慮 - 依存関係をシンプルに保つ - UIライブラリとして提供するのはこのあたりまで -
Organisms以上はそのアプリケーション固有の層 - 基本的にそのアプリケーションの外では再利用しない
TemplatesとPages - PagesはTemplatesに具体的なデータが入ったもの - つまりPages = 最終的なレンダリング結果 - コンポーネントはTemplatesまで作れば良い -
UIテスト用にPagesを定義するという手も
コンポーネントの管理
コンポーネントの管理 - そのままではコンポーネントの重複は免れない - Storybookなどの導入は事実上必須
コンポーネント間の依存関係
厳密に言えば、あるコンポーネントは 一つ下レイヤーのコンポーネントのみに依存する
ただし現実的には、この制約は結構つらい
コンポーネント間の依存関係 Atoms Molecules Organisms Templates 依存するもの なし Atoms Atoms Molecules
Organisms Organisms 依存の数 0 2つ以上 1つ以上 1つ以上
コンポーネント間の依存関係 Atoms Molecules Organisms Templates 依存するもの なし Atoms Atoms Molecules
Organisms Organisms 依存の数 0 2つ以上 1つ以上 1つ以上 ここは無理に 制限しない
データの受け渡し
Organisms Molecules Atoms Templates props props props event event event
『プロパティを渡して、イベントを受け取る』が原則
データの受け渡し - 親→子はプロパティ - 親は自分が受け取ったプロパティを、子に適切に振り分ける - Templates→Atomsでプロパティのサイズは小さくなるはず - 子→親はイベントハンドリング -
状態管理まわりなど、一部例外あり(後述)
状態管理
Organisms Molecules Atoms Templates props props props event event event
Store subscribe / dispatch (subscribe) /dispatch
Organisms Molecules Atoms Templates props props props event event event
Store subscribe / dispatch ここは汎用的に保ちたい → Storeにはアクセスしない (subscribe) /dispatch
Organisms Molecules Atoms Templates props props props event event event
Store (subscribe) /dispatch subscribe / dispatch アプリケーション固有のロジックは Templates、Organismsで処理 → Storeもアプリケーション固有
状態管理 Atoms Molecules Organisms Templates dispatch - - ◦ ◦
subscribe - - △ ◦
状態管理 Atoms Molecules Organisms Templates dispatch - - ◦ ◦
subscribe - - △ ◦ ※このあたりはプロジェクトの特性による
まとめ - Atomic DesignはあくまでUIデザインの手法 - そのままアプリケーション開発に使うとつらい - 制約が強い - そもそもプログラムとしての実装が考慮されていない
- アプリケーション開発のためには+αの設計が必要 - 考えないといけないことは結構多い
アプリケーション開発も考慮に入れた Alt Atomic Designの登場を待つのも手では?
Thank you !!