Vue.jsアーキテクチャリング勉強会
https://gyazo.com/a4538bafaca8a3b1fdba8b676c8be904
BASEにおけるVueコンポーネント設計
松原さん
フロントエンドチーム
内政のUIコンポーネントライブラリ
コンポーネントの種類
Container Components
Pagesに相当
API通信とStoreアクセスを許可
Presentational Components
副作用を持たず与えられたものを表示する
具体的なビジネスロジックと表現に寄ってる
副作用は考えない
Common Presentational Components
具体的なコンテキストがない使い回しができるもの
例：ヘッダーやパンくず
Atoms Components
個別だけではなくサービス全体で流用できるようにする
スタイルの局所的な上書きも許容できるようにScoped CSS / CSS Modulesを使わない
コンポーネント外との関係を決めるスタイルは当てない
margin, padding, z-index
サンドボックス
エンジニア向けのガイド
カタログ
網羅的に見れる
どちらかがかけてしまう可能性がある
knobsに頼りすぎると動かない
UIとして利用するものはカタログにする
コンポーネントごとにREADMEを置く
VueサポートがまだWIP
コンポーネントのレイヤごとに必要なこと
Containerは採用しない
フロントエンドの性質
ライフサイクルが短い
ドメインロジックに落としづらい
共通化もすぐ仕様が変わる
責務の分離をするためにコンポーネントをつくる
カプセル化する
疎結合を有線して多少の重複を恐れない
コードの塊で捨てられる状態
Tips
1. props
ObjectやArrayに型指定はやめる
PropTypeで渡す
HTML標準に沿った名前、汎用的な名前にする
2. event
カラフルな語彙を使わない
イベントの動詞：イベントの対象
例：openSearchBox
親に忖度した動詞名に寄せない
payloadにObjectを使う
RORO
emitするプロパティが増えても壊れにくい
3. style
classを条件分岐や処理で渋滞させない
一時的な状態に依存するスタイルと属性セレクタの組み合わせで当てる
4. scoped-slot
内部状態を一元管理するときは利用する
モーダル自身がトリガを持てるようにする
TeachmeBizを支えるフロントエンドのアーキテクチャと品質担保
笹木 信吾さん
状態管理
コンポーネント間での状態共有が容易
emit地獄は避けられる
画面単位での実装がしやすい
修正の範囲がわかる
画面総数＝開発規模となるので画面が増えていくと破綻していく
ドメインを考慮せずUI側に集中する
https://gyazo.com/052ec9888a85d1398a7bf715a9361ca0
https://gyazo.com/e3c66fde10edc4483f2222b0be730b9e
state
レスポンスをそのまま保持
action
複雑なAPIリクエストパラメータの構築を急襲
mutation
stateを更新する
getter＋モデル
APIの出力仕様を唯一理解する
メリット
Storeの責務が明確
UIがサーバーサイドの影響を受けない
テスタビリティが高い
Q: UIの状態をStoreで管理するのは辛くないか？
A: 意外と辛くない
大半がAPIから取得したドメインデータ
コンポーネント内で閉じた状態ならdataで持てばいい
多少のバケツリレーは受け入れるべき
といいつつあらゆる画面で使うUIの管理は別
フラッシュメッセージ
モーダルアラート 等
コンポーネントどう分割するか
メリット
下位コンポーネントは上位コンポーネントを知る必要が一切ない
再利用性が高い
Storeへのアクセスできる層を限定してテスタビリティを上げる
https://gyazo.com/b19cc14fc34b48c5ab2567c19fac6545
Pages
ユーザが一度に利用する画面そのもの
Store参照 可
Organisms
Moleculesを組み合わせてユーザにUXを提供
Store参照 可
Molecules
Atomsを組み合わせて単一の機能を提供
Store参照 不可
Atoms
これ以上分割できないUIの最小単位
Store参照 不可
コンポーネントの品質をどう評価するか
knobsでロケールを切り替える
Storeをモックしてサーバなしで画面遷移する
プルリクを出した時点でS3に静的ビルドしたものをアップ テストコードをどう書くか
コンポーネントテスト
propsとdataによる振る舞いの変化を検証
Organismに絞って検証
デザインテスト
実験中
Storeテスト
Action
APIリクエストパラメータを正しく組み立てる
適切なMutationをコミット
Mutation
パラメータに応じてStateを更新する
getter
APIレスポンスから生成したモデルが取得できるか
総評
テストの責務がわかりやすい
API仕様側のデグレを検証しやすい
カバレッジ100にしようとすると実装と同じコードを書きがち
何をモックして何をテストしているかを理解する
entakuさん
利用技術
足したもの
Utils系
今回話す主な範囲のイメージ
Actions
State
Mutations
Components
Pages
HTML, CSS, JS
コンポーネントの呼び出し
import Components
Viewで描写する
map
state
データの保管先
mutations
データの変更
getters
データの取得
参照処理
actions
データの更新処理
commit()
失敗したこと
Stateの直接参照
Actionを通さないMutationsの処理を書いてしまった
なぜ不味いか？
Vuexに保存されているデータを何も介さなくなる・情報の一意性が保てない vueファイルに内在してしまう
デザインについて
Atoms
element-uiコンポーネントのラッパーorそのもの
Molecules
1つ以上のAtomsを利用しているもの
Organisms
複数のMoleculesを利用しているもの
Templates
失敗
カスタムで作ってしまったUI
デザインシステムが構築できてなかった
Templatesを入れずに開発してしまった
無限emit地獄
開発言語
types
データの定義
index/state
データの保管先
getters
データの取得
Vue.js設計地図 〜設計概念の依存関係からフロントエンド設計を見つめ直す〜 大平和史さん
サービスの企画から設計をどうするか
問題
デザイナー、ビジネス、エンジニアで認識があってない
ルーティング、ディレクトリ設計があっちこっちいってる
依存関係について考える
そもそも現在地はどこなのか
地図が必要なのではないか
https://gyazo.com/410c45f906b3ce29c058889ecdba2c85
モデリングを決めると
Howが決まる
ストアの設計が決まる
依存関係をベースに、モデリングベースで設計したことの評価・所感
新規観点
新規で実装する際に、思考スキームが設計概念として可視化されていることで、自分の立ち位置を把握しながら、順序を追って進捗させることができた
設計の手探り感がなくなり、以前よりも手戻りも少なくスムーズに設計開発することができました。
モデル起点とするため、モデリングさえしっかりしてしまえば、システムの構成としてはあまり悩むことなく開発できたと思う
修正観点
一度コードを書いたあと、ディレクトリ構成を若干変える必要があったりしたのですが、元の考え方が明確になっているため、比較的構成の若干の変更はしやすかったと思う