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
600
Atomic Design周りについての私見
ITのむずかしいを簡単にする会 - LT会 #5(2018/11/29)の発表資料です。
ponday
November 29, 2018
Tweet
Share
More Decks by ponday
See All by ponday
関数型でGoFのデザインパターンやってみる
honda
0
1.1k
TypeScriptの型表現
honda
10
2.9k
Web Componentsの今
honda
1
380
これまでのReact、これからのReact
honda
0
270
Gatsbyお試し
honda
0
110
styled-components or emotion?
honda
0
630
Web ComponentsとAngular
honda
0
130
え、まだWeb Componentsを未来の技術だと思ってるの?
honda
2
720
Web Componentsの動向とPolymer
honda
4
2.3k
Other Decks in Programming
See All in Programming
Pythonで改めて考える「クラス(class)」の使いどころ
os1ma
1
470
Kotlin 2.0が与えるAndroid開発の進化
masayukisuda
1
410
Rubyとクリエイティブコーディングの輪の広がり / The Growing Circle of Ruby and Creative Coding
chobishiba
1
270
KSPの導入・移行を前向きに検討しよう!
shxun6934
PRO
0
280
Rubyのobject_id
qnighy
6
1.3k
LangChainの現在とv0.3にむけて
os1ma
4
920
Increased Performance and Developer Productivity with Jakarta EE 11
ivargrimstad
0
380
意外とフォントが大事だった話 / Font Issues on Internationalization
fumi23
0
110
watsonx.ai Dojo #2 生成AIを使ったアプリ開発入門編
oniak3ibm
PRO
0
180
仮想ファイルシステムを導入して開発環境のストレージ課題を解消する
segadevtech
2
550
あなたのアプリ、ログはでてますか?あるいはログをだしてますか? (Funabashi.dev用 軽量版)
uzulla
2
120
A New Era of Testing
mannodermaus
2
510
Featured
See All Featured
Agile that works and the tools we love
rasmusluckow
327
20k
Art, The Web, and Tiny UX
lynnandtonic
294
20k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
227
52k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
27
7.4k
Writing Fast Ruby
sferik
623
60k
Scaling GitHub
holman
458
140k
Atom: Resistance is Futile
akmur
261
25k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
26
1.9k
A better future with KSS
kneath
235
17k
How To Stay Up To Date on Web Technology
chriscoyier
786
250k
How GitHub Uses GitHub to Build GitHub
holman
472
290k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
36
2.1k
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 !!