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
100
Stable Diffusionで遊んでみた
seiyasugimoto
0
110
EVAフレームワーク
seiyasugimoto
0
78
SSR+SPA
seiyasugimoto
0
110
Nuxtにおける設計
seiyasugimoto
0
77
throttleすげぇぇぇ
seiyasugimoto
0
75
スマホでPythonしたい
seiyasugimoto
0
60
平文で保存するな!
seiyasugimoto
0
82
ソースコードを読もう
seiyasugimoto
0
77
Other Decks in Programming
See All in Programming
GoogleI/O2024 LT報告会資料
shinsukefujita1126
0
110
いまどきの分析設計パターン10選
masuda220
PRO
28
9.6k
Adding Tests to Untestable Legacy Code
afilina
PRO
0
120
どこでも使える Cloudflare Workers!
codehex
6
450
BigQueryとDataformとTROCCO®による事業グロース
nihemak
0
190
あらゆるアプリをCompose Multiplatformで書きたい! -ネイティブアプリの「あの機能」を私たちはどう作るか-
subroh0508
0
160
詳解 "Fixing For Loops in Go 1.22" 自作linterをgolangci-lintへコントリビュートした話
qualiarts
9
830
Deriving derived state: derivedStateOf explained (dcSF 24)
zachklipp
1
170
Android アプリのプロジェクトをモダンにし続ける工夫
numeroanddev
1
380
Automatisiere deine Prozesse mit GitHub Actions!
ahus1
0
260
Gobra で見る形式検証 (mercari.go #26)
artoy
0
390
Bottom-Up Architecture – Bridging the Achitecture Code Gap
olivergierke
3
120
Featured
See All Featured
How To Stay Up To Date on Web Technology
chriscoyier
784
250k
How GitHub (no longer) Works
holman
305
140k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
247
20k
KATA
mclloyd
18
12k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
24
1.7k
Writing Fast Ruby
sferik
623
60k
Designing for Performance
lara
603
67k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
23
1.5k
BBQ
matthewcrist
80
8.9k
Into the Great Unknown - MozCon
thekraken
16
1.2k
Design by the Numbers
sachag
276
18k
Designing with Data
zakiwarfel
96
4.9k
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以外でのデータの受け渡しを禁止