BASEにおける Vueコンポーネント設計の現在

by simezi9

Slide 1

Slide 1 text

Slide 2

Slide 2 text

⾃⼰紹介 © - BASE, Inc. 松原佑介フロントエンドエンジニア 2018年9⽉BASE⼊社 : simezi

Slide 3

Slide 3 text

BASEのプロダクト © - BASE, Inc. ネットショップ作成サービス「BASE」ショッピングアプリ「BASE」 Payment to the People, Power to the People MISSION

Slide 4

Slide 4 text

Slide 5

Slide 5 text

BASEのフロントエンド開発の現状 © - BASE, Inc. サーバーサイド：PHP, Go フロントエンドエンジニア：6名フロントエンド：Vue.js, TypeScript, Sketch デザイナー：8名（2019年10⽉時点）

Slide 6

Slide 6 text

フロントエンドチームは何をしてきたか © - BASE, Inc. • 管理画⾯刷新プロジェクト開始で jQueryからVue.js+TS化 • SPAではなく、⼤きな機能単位で MPA(Multi Page Application)化 • 内製のUIコンポーネントライブラリの作成 ࣍ͷ5೥Λࢧ͑ΔVue.js੡UIίϯϙʔωϯτϥΠϒϥϦΛҭͯΔ

Slide 7

Slide 7 text

今ではプロジェクト開始から約1年半 © - BASE, Inc. 本⽇はそこで追加で得られたコンポーネントづくりの知⾒について話します

Slide 8

Slide 8 text

おしながき © - BASE, Inc. BASEでのコンポーネント設計 Storybookの整備個別のコンポーネントの実装

Slide 9

Slide 9 text

Slide 10

Slide 10 text

コンポーネントの種類 © - BASE, Inc. Atomic DesignとContainer Componentの考え⽅を借りて、役割に応じて⼤きく4つに分類 . Container Component . Presentational Component . Common Presentational Component . Atom Component ( UIライブラリ )

Slide 11

Slide 11 text

コンポーネントの種類 © - BASE, Inc. コンポーネントを役割に応じて⼤きく4つに分類 . Container Component . Presentational Component . Common Presentational Component . Atom Component ( UIライブラリ )

Slide 12

Slide 12 text

Container Component © - BASE, Inc. • Atomic DesignでいうPageに相当 • API通信、Storeへのアクセスを⾏うことができる唯⼀のコンポーネント • 複数のPresentational ComponentやContainer Componentを束ねる役割 • ContainerComponentの中に多少のUIを持つことは認める

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Presentational Component © - BASE, Inc. • Template/Organismに相当 • 副作⽤を持たず、与えられたプロパティを表⽰するだけのコンポーネント • 具体的なビジネスロジック‧表現に紐づくため再利⽤性は考えないコンポーネント • ContainerComponentと PresentationalComponentはディレクトリを分けず、名前で区別する

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Common Presentational Component © - BASE, Inc. • Template / Organism / Moleculeに相当 • Presentational Componentの中でアプリケーションの内部で頻出するデザインのパターンを定義する • 例）全体のヘッダーやページのパンくずとタイトル • 具体的なコンテキストがない抽象的で使い回しができるコンポーネント群

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Atom Component © - BASE, Inc. • Atomic DesignでいうMolecule/Atomに相当 • 個別のアプリケーションにとどまらず、サービス全体で流⽤できるような⼩さいコンポーネント群 • form部品やbuttonなどの利⽤頻度がたかいもの • スタイルの局所的な上書きも許容できるように Scoped CSS / CSS Modulesを使わない • コンポーネント外との関係を決めるスタイルは当てない例) margin, float, z-index‧‧‧etc

Slide 19

Slide 19 text

概念図 © - BASE, Inc.

Slide 20

Slide 20 text

概念図 © - BASE, Inc. ΠϕϯτͷྲྀΕ

Slide 21

Slide 21 text

概念図 © - BASE, Inc. ֎෦ͱͷ௨৴͸ Container͚ͩͰߦ͏

Slide 22

Slide 22 text

概念図 © - BASE, Inc. Common/Presentational ͸ͲͪΒͰ΋਌ʹͳΕΔ

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Storybookに求められる2つの役割 © - BASE, Inc. .サンドボックス実際のコードに対してどう動くかを試す環境実装の際のエンジニア向けガイドとしての働き .カタログ提供されているコンポーネントを網羅的に⾒るどちらかの要素が⽋けたものが出来上がりがち

Slide 25

Slide 25 text

サンドボックス性の⾜りないStorybook © - BASE, Inc. 昔ながらのUIカタログの機能しかないケース • やりたいことはわかっても渡すべきprops、キャッチすべきevent、他コンポーネントとの組み合わせなど、実装に必要な情報が⾜りない • storybookに置く意味があまりない • 実装を意識しないならsketch上にあるだけでいい

Slide 26

Slide 26 text

カタログ性の⾜りないStorybook © - BASE, Inc. 実装者が作るだけ作って満⾜してしまったケース • コンポーネントが⼀個おいてあるだけ想定されている使い⽅が伝わらない • knobsに⼤量のパラメータパラメータの組み合わせもわからず、作った⼈にしかわからない。特にデザイナーとはコミュニケーションが難しい協業の場として機能しない

Slide 27

Slide 27 text

storybookを機能させるために © - BASE, Inc. • Knobsに頼りすぎない • あくまでknobsは補助 • UIとして利⽤するパターンはなるべく⼀覧できるように(= カタログ) • 実装に必要な情報はきちんと書く(=サンドボックス) • コンポーネントごとにREADME.mdを⽤意する

Slide 28

Slide 28 text

コンポーネントごとのREADME.md © - BASE, Inc. @storybook/addon-notesで読み込む必要な情報 • 簡単なサンプルコード • 動作の仕様 • Propsの値、型、デフォルト値 • Eventの発⽕タイミング、payload • slotの名前 • scoped-slotで渡される値 …etc 将来的には@storybook/addon-docsで markdownを活⽤できるようになるはず（現在はVueのサポートがWIP)

Slide 29

Slide 29 text

コンポーネントのレイヤ別に必要なこと © - BASE, Inc. ίϯϙʔωϯτͷछྨ Χλϩάੑ αϯυϘοΫεੑ Container Storybook্ʹ ొ࿥͠ͳ͍ Presentational ௿ ௿ Common ௿ ߴ Atom ߴ ߴ レイヤの低い抽象的なコンポーネントほど説明が必要

Slide 30

Slide 30 text

Slide 31

Slide 31 text

フロントエンドの性質 © - BASE, Inc. • フロントエンドのコードはライフサイクルが短い • 修正＝全取替であることが珍しくない • ドメインロジックに落としづらい細かい分岐の連続 • 例)ある⼀箇所だけ「0円」を「無料」にしたい… • 共通化しても仕様がすぐに変わってしまう

Slide 32

Slide 32 text

Slide 33

Slide 33 text

コンポーネントの責務の分離 © - BASE, Inc. • コンポーネントで作ることでスタイル、マークアップ、スクリプトを外部に影響しない形でカプセル化できる • 作る側もとにかく疎結合を優先して、類似コードの重複を恐れない。 • 本当に必要なパターンと確定したら共通化する • いつでもコードの塊で捨てられる状態をキープする

Slide 34

Slide 34 text

実装のtips① props © - BASE, Inc. • ObjectやArrayを型に指定するのはなるべく避ける特にTSを採⽤している場合にはPropTypeを使う props: { deliveryInfo: { type : Array as PropType }, payment: { type : String as PropType, } },

Slide 35

Slide 35 text

実装のtips① props © - BASE, Inc. • HTML標準に沿った名前、汎⽤的な名前をつかう ίϯϙʔωϯτར༻ऀ͔ΒΈͨࣗવͳΠϯλʔϑΣΠεΛ৺͕͚Δ name: 'AppInput', props: { id: String, name: String, type: String, value: { default: '', type: [String, Number], }, placeholder: String, }

Slide 36

Slide 36 text

実装のtips②event © - BASE, Inc. • イベント名にカラフルな語彙を使わない BASEͰ͸ {Πϕϯτͷಈࢺ}:{Πϕϯτͷର৅} ͱ͍͏ϑΥʔϚοτΛར༻͍ͯ͠Δ ྫ) update:someValue • XMLͷ໊લۭؒͷϑΥʔϚοτʹ߹Θͤͯಈࢺ+(͋Ε͹໨తޠ)ͷܗࣜ • ಈࢺͷޠኮΛߜΓγϯϓϧͳ୯ޠΛ࢖͏͜ͱͰݟ௨͕͕͋͠Δ • ಛʹಈࢺ͸਌ίϯϙʔωϯτʹ ዁౓ͨ͠Πϕϯτ໊Λ͚ͭͳ͍

Slide 37

Slide 37 text

実装のtips②event © - BASE, Inc. • イベントのpayloadにObjectを使う • RORO(Receive an object, return an object) • emitするプロパティが増えても壊れにくい // emit͢Δଆ this.$emit('change', { enabled: defaults, dirty: false }) // ड͚औΔଆɹ updateShippingFee({ enabled, dirty }) { // Objectͷ෼ׂ୅ೖͰड͚औΔ this.$store.useCase(new EditItemDetail()).updateShippingFee(enabled, dirty) }

Slide 38

Slide 38 text

Slide 39

Slide 39 text

実装のtips③style © - BASE, Inc. • ⼀時的な状態に依存するスタイルはdata-*やaria-* と属性セレクタの組み合わせで当てる • 例) ローディング中、選択中か、など .foo { &[aria-selected="true"] { color: $green; } &[aria-selected="false"] { color: $gray; } }

Slide 40

Slide 40 text

実装のtips④scoped-slot © - BASE, Inc. コンポーネントの内部状態を⼀元管理するコンポーネントが欲しくなる場合にはscoped-slotを利⽤する例) • テーブルのヘッダとリストの結びつき管理 • モーダルのトリガとなるコンポーネントとモーダルのコンテンツ

Slide 41

Slide 41 text

ίϯςϯπ

Slide 42

Slide 42 text

まとめ © - BASE, Inc. • コンポーネントでいちばん⼤事なのは責務の分離 • 特にContainerとPresentationalなコンポーネントの役割わけをきっちり守るのは重要 • いつでもコード(特にUI側)を捨てられるように。 • Storybookには広い利⽤者に向けたおもてなしの⼼が必要 • ちょっとした⾶び道具的な修正でコンポーネントの前提が壊れても泣かない