Atomic Designを ディレクトリ以外で表現

Transcript

1. Atomic Designを ディレクトリ以外で表現 ディレクトリは直交する分類を扱えないのでは？
2. しぐまです • NLPシニアエンジニア • 25歳 • Nuxtとか
3. Atomic Designでディレクトリ切ると辛い • ひとまとまりのコンポーネントがバラバラに ◦ /components/molecules/HogeListItem.vue ◦ /components/organisms/HogeList.vue ◦ OMG…！ • moleculesが肥大化してorganismsに ◦ 動かしたら参照が切れてしまう ◦ 出来なくはないけど結構面倒
4. 何故辛いのか • ディレクトリ構造で直交する2つの基準による分類を表現しようとしている ◦ Atomic Design ◦ 機能による分類 • ディレクトリによる分類の性質 ◦ 単純な木構造で表現力は高くはない。 ◦ あちこちからディレクトリ指定で参照されるため再分類が難しい。 • 機能による分類をディレクトリ構造で表現し、Atomic Designによる分類をメタ情報 で表現すれば辛くないのでは？
5. 最初Storybookを考えた • Storybookのグループ機能 • Atomic Designに基づいた分類をStorybook上でやるのは聞いたことがあった（デ ファクト？
6. ちょっとオーバースペック感否めなかった • 様々な理由で見送り ◦ Storybookはビジュアルリグレッションテスト等を実行できてリリース後のアップデートの工数を激減 させるのは分かっていたが、フロントエンドはロジックを抽出してテストをする以上の自動テストはや らない方針だった。 ◦ XD、HTML/CSSがあってそれをコンポーネントに落とし込む開発フローだったため、開発中にコン ポーネントをプレビュー出来ることによるメリットが薄かった。 ◦ 開発工数が潤沢でなかった。 • こういう場合どうするかについての解が欲しい
7. Group機能がある軽量なドキュメンテーションツール • Vueseが良さげ
8. ファイル構造は機能を表現したものにできる
9. 粒度についてチームで議論できる体制を整える • Atomic Designに開発者が求めていることは多くの場合「コンポーネント粒度につ いてチームで議論できる体制を整える」ということだと思う。 • orgsnismsとmoleculesの境目を自分たちの言葉で定め、軽量なドキュメンテーショ ンツールによって分類することでこれは達成出来る。 ◦ atomsは多くの場合わかりやすい。 ◦ templatesはlayouts, pagesはpagesに対応している。 • 能書きより対話
10. AND MORE 「Nuxtにおけるデータの渡し方問題」 • Nuxtにおけるデータの受け渡し方問題 ◦ Propsで渡すかSroreを経由するかについて破綻しやすい。 ◦ 粒度と強い相関のある概念のため Atomic Designと関連付ける。 • 粒度によって決めてしまう手 ◦ pagesにはasyncData, fetchによるデータの取得を許可 ◦ organismにはfetchによるデータ取得を許可 ◦ molecules, atomsにはProps以外でのデータの受け渡しを禁止