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
AIともっと楽するE2Eテスト
myohei
7
2.9k
Railsアプリケーションと パフォーマンスチューニング ー 秒間5万リクエストの モバイルオーダーシステムを支える事例 ー Rubyセミナー 大阪
falcon8823
5
1.4k
PHPでWebSocketサーバーを実装しよう2025
kubotak
0
300
PipeCDのプラグイン化で目指すところ
warashi
1
290
Webの外へ飛び出せ NativePHPが切り拓くPHPの未来
takuyakatsusa
2
570
初学者でも今すぐできる、Claude Codeの生産性を10倍上げるTips
s4yuba
16
12k
明示と暗黙 ー PHPとGoの インターフェイスの違いを知る
shimabox
2
580
iOS 26にアップデートすると実機でのHot Reloadができない?
umigishiaoi
0
130
新メンバーも今日から大活躍!SREが支えるスケールし続ける組織のオンボーディング
honmarkhunt
5
8k
状態遷移図を書こう / Sequence Chart vs State Diagram
orgachem
PRO
2
160
ruby.wasmで多人数リアルタイム通信ゲームを作ろう
lnit
3
500
AI コーディングエージェントの時代へ:JetBrains が描く開発の未来
masaruhr
1
200
Featured
See All Featured
The Art of Programming - Codeland 2020
erikaheidi
54
13k
The World Runs on Bad Software
bkeepers
PRO
69
11k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.5k
How GitHub (no longer) Works
holman
314
140k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
830
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Bash Introduction
62gerente
613
210k
Optimizing for Happiness
mojombo
379
70k
Gamification - CAS2011
davidbonilla
81
5.4k
Statistics for Hackers
jakevdp
799
220k
How STYLIGHT went responsive
nonsquared
100
5.6k
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以外でのデータの受け渡しを禁止