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
Sigma
October 10, 2022
Programming
0
79
Atomic Designを ディレクトリ以外で表現
Sigma
October 10, 2022
Tweet
Share
More Decks by Sigma
See All by Sigma
Proxmox_VE.pdf
seiyasugimoto
0
190
Stable Diffusionで遊んでみた
seiyasugimoto
1
130
EVAフレームワーク
seiyasugimoto
0
100
SSR+SPA
seiyasugimoto
0
130
Nuxtにおける設計
seiyasugimoto
0
88
throttleすげぇぇぇ
seiyasugimoto
0
77
スマホでPythonしたい
seiyasugimoto
0
66
平文で保存するな!
seiyasugimoto
0
87
ソースコードを読もう
seiyasugimoto
0
81
Other Decks in Programming
See All in Programming
第9回 情シス転職ミートアップ 株式会社IVRy(アイブリー)の紹介
ivry_presentationmaterials
1
290
iOS 26にアップデートすると実機でのHot Reloadができない?
umigishiaoi
0
130
Code as Context 〜 1にコードで 2にリンタ 34がなくて 5にルール? 〜
yodakeisuke
0
120
PHP 8.4の新機能「プロパティフック」から学ぶオブジェクト指向設計とリスコフの置換原則
kentaroutakeda
2
760
XP, Testing and ninja testing
m_seki
3
240
10 Costly Database Performance Mistakes (And How To Fix Them)
andyatkinson
0
260
VS Code Update for GitHub Copilot
74th
2
630
Azure AI Foundryではじめてのマルチエージェントワークフロー
seosoft
0
160
技術同人誌をMCP Serverにしてみた
74th
1
630
Result型で“失敗”を型にするPHPコードの書き方
kajitack
5
610
LT 2025-06-30: プロダクトエンジニアの役割
yamamotok
0
730
Hypervel - A Coroutine Framework for Laravel Artisans
albertcht
1
110
Featured
See All Featured
Balancing Empowerment & Direction
lara
1
430
For a Future-Friendly Web
brad_frost
179
9.8k
Git: the NoSQL Database
bkeepers
PRO
430
65k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Navigating Team Friction
lara
187
15k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
The Invisible Side of Design
smashingmag
301
51k
Making the Leap to Tech Lead
cromwellryan
134
9.4k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.4k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
How STYLIGHT went responsive
nonsquared
100
5.6k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Transcript
Atomic Designを ディレクトリ以外で表現 ディレクトリは直交する分類を扱えないのでは?
しぐまです • NLPシニアエンジニア • 25歳 • Nuxtとか
Atomic Designでディレクトリ切ると辛い • ひとまとまりのコンポーネントがバラバラに ◦ /components/molecules/HogeListItem.vue ◦ /components/organisms/HogeList.vue ◦ OMG…!
• moleculesが肥大化してorganismsに ◦ 動かしたら参照が切れてしまう ◦ 出来なくはないけど結構面倒
何故辛いのか • ディレクトリ構造で直交する2つの基準による分類を表現しようとしている ◦ Atomic Design ◦ 機能による分類 • ディレクトリによる分類の性質
◦ 単純な木構造で表現力は高くはない。 ◦ あちこちからディレクトリ指定で参照されるため再分類が難しい。 • 機能による分類をディレクトリ構造で表現し、Atomic Designによる分類をメタ情報 で表現すれば辛くないのでは?
最初Storybookを考えた • Storybookのグループ機能 • Atomic Designに基づいた分類をStorybook上でやるのは聞いたことがあった(デ ファクト?
ちょっとオーバースペック感否めなかった • 様々な理由で見送り ◦ Storybookはビジュアルリグレッションテスト等を実行できてリリース後のアップデートの工数を激減 させるのは分かっていたが、フロントエンドはロジックを抽出してテストをする以上の自動テストはや らない方針だった。 ◦ XD、HTML/CSSがあってそれをコンポーネントに落とし込む開発フローだったため、開発中にコン ポーネントをプレビュー出来ることによるメリットが薄かった。
◦ 開発工数が潤沢でなかった。 • こういう場合どうするかについての解が欲しい
Group機能がある軽量なドキュメンテーションツール • Vueseが良さげ
ファイル構造は機能を表現したものにできる
粒度についてチームで議論できる体制を整える • Atomic Designに開発者が求めていることは多くの場合「コンポーネント粒度につ いてチームで議論できる体制を整える」ということだと思う。 • orgsnismsとmoleculesの境目を自分たちの言葉で定め、軽量なドキュメンテーショ ンツールによって分類することでこれは達成出来る。 ◦ atomsは多くの場合わかりやすい。
◦ templatesはlayouts, pagesはpagesに対応している。 • 能書きより対話
AND MORE 「Nuxtにおけるデータの渡し方問題」 • Nuxtにおけるデータの受け渡し方問題 ◦ Propsで渡すかSroreを経由するかについて破綻しやすい。 ◦ 粒度と強い相関のある概念のため Atomic
Designと関連付ける。 • 粒度によって決めてしまう手 ◦ pagesにはasyncData, fetchによるデータの取得を許可 ◦ organismにはfetchによるデータ取得を許可 ◦ molecules, atomsにはProps以外でのデータの受け渡しを禁止