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
690
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.2k
TypeScriptの型表現
honda
10
3k
Web Componentsの今
honda
1
420
これまでのReact、これからのReact
honda
0
310
Gatsbyお試し
honda
0
110
styled-components or emotion?
honda
0
680
Web ComponentsとAngular
honda
0
130
え、まだWeb Componentsを未来の技術だと思ってるの?
honda
2
810
Web Componentsの動向とPolymer
honda
4
2.5k
Other Decks in Programming
See All in Programming
rbs-traceを使ってWEARで型生成を試してみた After RubyKaigi 2025〜ZOZO、ファインディ、ピクシブ〜 / tried rbs-trace on WEAR
oyamakei
0
1k
AIにコードを生成するコードを作らせて、再現性を担保しよう! / Let AI generate code to ensure reproducibility
yamachu
7
6k
RubyKaigi Hack Space in Tokyo & 函館最速 "予習" 会 / RubyKaigi Hack Space in Tokyo & The Fastest Briefing of RubyKaigi 2026 in Hakodate
moznion
1
120
CQRS/ESのクラスとシステムフロー ~ RailsでフルスクラッチでCQRSESを組んで みたことから得た学び~
suzukimar
0
190
Cloudflare Realtime と Workers でつくるサーバーレス WebRTC
nekoya3
0
230
TVer iOSチームの共通認識の作り方 - Findy Job LT iOSアプリ開発の裏側 開発組織が向き合う課題とこれから
techtver
PRO
0
700
primeNumberでのRBS導入の現在 && RBS::Traceでinline RBSを拡充してみた
mnmandahalf
0
250
ワンバイナリWebサービスのススメ
mackee
10
7.4k
型付け力を強化するための Hoogle のすゝめ / Boosting Your Type Mastery with Hoogle
guvalif
1
230
iOSアプリ開発もLLMで自動運転する
hiragram
6
2.1k
MLOps Japan 勉強会 #52 - 特徴量を言語を越えて一貫して管理する, 『特徴量ドリブン』な MLOps の実現への試み
taniiicom
2
560
OpenTelemetryで始めるベンダーフリーなobservability / Vendor-free observability starting with OpenTelemetry
seike460
PRO
0
160
Featured
See All Featured
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3k
Unsuck your backbone
ammeep
671
58k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.5k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.2k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
The Cost Of JavaScript in 2023
addyosmani
49
8k
Why Our Code Smells
bkeepers
PRO
336
57k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Building Better People: How to give real-time feedback that sticks.
wjessup
368
19k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
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 !!