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
200
Stable Diffusionで遊んでみた
seiyasugimoto
1
130
EVAフレームワーク
seiyasugimoto
0
100
SSR+SPA
seiyasugimoto
0
130
Nuxtにおける設計
seiyasugimoto
0
89
throttleすげぇぇぇ
seiyasugimoto
0
77
スマホでPythonしたい
seiyasugimoto
0
66
平文で保存するな!
seiyasugimoto
0
87
ソースコードを読もう
seiyasugimoto
0
85
Other Decks in Programming
See All in Programming
AIと人間の共創開発!OSSで試行錯誤した開発スタイル
mae616
1
640
overlayPreferenceValue で実現する ピュア SwiftUI な AdMob ネイティブ広告
uhucream
0
190
CSC509 Lecture 06
javiergs
PRO
0
260
AI Agent 時代的開發者生存指南
eddie
3
1.8k
PHPに関数型の魂を宿す〜PHP 8.5 で実現する堅牢なコードとは〜 #phpcon_hiroshima / phpcon-hiroshima-2025
shogogg
1
240
Pull-Requestの内容を1クリックで動作確認可能にするワークフロー
natmark
2
520
3年ぶりにコードを書いた元CTOが Claude Codeと30分でMVPを作った話
maikokojima
0
510
はじめてのDSPy - 言語モデルを『プロンプト』ではなく『プログラミング』するための仕組み
masahiro_nishimi
2
560
CSC509 Lecture 03
javiergs
PRO
0
340
TFLintカスタムプラグインで始める Terraformコード品質管理
bells17
2
210
Railsだからできる 例外業務に禍根を残さない 設定設計パターン
ei_ei_eiichi
0
930
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
400
Featured
See All Featured
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.5k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
3.7k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Done Done
chrislema
185
16k
For a Future-Friendly Web
brad_frost
180
10k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
Building an army of robots
kneath
306
46k
Git: the NoSQL Database
bkeepers
PRO
431
66k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
115
20k
Leading Effective Engineering Teams in the AI Era
addyosmani
7
450
Building a Modern Day E-commerce SEO Strategy
aleyda
44
7.8k
Designing for Performance
lara
610
69k
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以外でのデータの受け渡しを禁止