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
67
Atomic Designを ディレクトリ以外で表現
Sigma
October 10, 2022
Tweet
Share
More Decks by Sigma
See All by Sigma
Proxmox_VE.pdf
seiyasugimoto
0
98
Stable Diffusionで遊んでみた
seiyasugimoto
0
110
EVAフレームワーク
seiyasugimoto
0
76
SSR+SPA
seiyasugimoto
0
110
Nuxtにおける設計
seiyasugimoto
0
75
throttleすげぇぇぇ
seiyasugimoto
0
75
スマホでPythonしたい
seiyasugimoto
0
60
平文で保存するな!
seiyasugimoto
0
82
ソースコードを読もう
seiyasugimoto
0
77
Other Decks in Programming
See All in Programming
Strategien, Taktiken und Muster der Legacy-Ablösung
tobiaslvoss
0
120
Rubykaigiの振り返り/fbc-meetup-20240530
yswengineer
0
5.7k
From Spring Boot 2 to Spring Boot 3 with Java 22 and Jakarta EE
ivargrimstad
0
100
マイクロサービス基盤にフルマネージドサービスではなくKubernetesを選択する理由
bgpat
6
240
Streaming I/O
macdice
0
230
Swift Attributes
hokuron
0
230
通信の不安定さに悩んでいたらシュッとプロキシを書けて改善できちゃった話
bellwood4486
2
330
DroidKnights 2024 - Compose UI 컴포넌트 설계와 테스트
wisemuji
0
530
ReactNativeでスケジュール帳を作っている話
mokoshi
0
170
チームで運用する golangci-lint の向き合い方
sgash708
0
110
Is Efficiency a Good Thing?
hollycummins
1
130
Vertical Architectures for Scalable Angular Applications
manfredsteyer
PRO
0
130
Featured
See All Featured
Building Effective Engineering Teams - LeadDev
addyosmani
39
2k
Building a Scalable Design System with Sketch
lauravandoore
457
32k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
34
6.2k
Imperfection Machines: The Place of Print at Facebook
scottboms
261
12k
From Idea to $5000 a Month in 5 Months
shpigford
377
46k
Docker and Python
trallard
36
2.8k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3.1k
What’s in a name? Adding method to the madness
productmarketing
PRO
18
2.8k
Scaling GitHub
holman
457
140k
WebSockets: Embracing the real-time Web
robhawkes
59
7.1k
4 Signs Your Business is Dying
shpigford
176
21k
It's Worth the Effort
3n
180
27k
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以外でのデータの受け渡しを禁止