https://gyazo.com/9c328ed21a0bb4f5fbd44c2e02457bac
vite 〜Native-ESM powered web dev build tool. It's fast.〜 現在 v0.20.8
What is Vite ?
モダンフロントエンドビルドツール
生まれた背景
SFCでES Modulesを動かしたい
Vueのコア部分はできている
アイデア
SFCはバンドルなしで動かせるのではないか？
特徴
DevServerの立ち上げが早い
コンパイルがオンデマンド
bundlerと違うもの
開発中はbundleしない
Viteはなぜ速い
esbuild
TSのビルドが20倍早い
HTTPリクエストごとにコンパイルしている
画面単位で更新
ローカル上でも解決するようにしている
node_modulesを解決している
キャッシュ
レスポンスは304で返す
サーバー
プラグイン
Module Rewrite Server Plugin
JSを書き換える
/@modules/:id
相対パスはソースコード上パス＋タイムスタンプ
HTML Rewrite Server Plugin
index.htmlにランタイムコードを埋め込む
Vue Server Plugin
SFCをコンパイル
templateとstyleで別れてビルドされる
HMR Server Plugin
self-accept module
import.meta.hot.accept
自分自身で解析処理を行う
ビルドツール
今後の予定
テストが必要
モジュールの依存関係解消
エラーメッセージ
ぼくのかんがえたさいきょうのVueあーきてくちゃ
ディレクションの知識
大規模アプリで利用できる
遷移
参照
一覧
ロジックが共通化できそう
新規作成・削除
詳細
共通化の余地がない
編集
権限
参照・操作のDOM表示とAPIリクエスト
バリデーション
最強のアーキテクチャ
見通しの良い構成
MVVMのViewModelを分ける
composition API
100行に満たないコンポーネントはSFCにする
SetupContext
それ以外の処理やビジネスロジックを分ける
ディレクトリ
https://gyazo.com/b2b137c24043a498823bcaca76e7fb86
plugins
外部ライブラリの読み込む
enums
ネームスペースをオーバーライドしてメソッド生やす
文字列比較できる
models
APIクライアント
BaseModelはREST APIリクエストの取り扱いを簡易にする
共通処理を書く
extend
エンティティのプロパティに集中
modules
単体テストしやすい
mixins
SetupContextを利用
emit
$touter, $store
dataをリアクティブのオブジェクトにする
APIリクエストはmodels
ビジネスロジックはmodulesから引っ張る
そのほか
viesのコンポーネントは画面数と1to1
componentsに入れるに大きすぎるのはtemplatesに
等しく使われるリソース
処理≠ロジック
Vue.observable で状態を管理する
背景
ページを超える状態管理をする必要
エラー状態
ユーザー状態
管理画面の用途
モチベーション
グローバルな状態管理
モジュールモード
ディレクトリ構成と対応するプロパティが動的に生える
求めてるのは単方向データフローではない
Vue.observable
2.6から追加されたAPI
オブジェクトをリアクティブにできる
https://gyazo.com/7231038df82a876406f9f35e0b26b922
エラーハンドリング
Vue.config.errorHandlerに登録されている関数が呼ばれる
サンプル
利点
v-ifで分岐してSnackbarやモーダルを表示
サーバー上でレンダリングする
Google Optimize
ABテスト
GUIでテストできる
アナリティクスと連携できる
「Optimizeを使いたい」
Androidで動かないとは？
Tag Managerの設定を変えた
動かなかった
PCも動かない
一瞬変わってもとに戻っている
hydration
静的なHTMLを動的なDOMにする
見えるけど操作できない状態
DOMを破棄して１から描画
https://gyazo.com/3d9a2ef3ff4f63c77860c0320d4ec6a5
解決
hydrationのあとにテストの起動・実行
mounted
onNuxtReady
v2.1.2
pakages/core/src
nuxt.js
class Nuxt
this._initServer()
レンダーの処理
pacakegs/server/src/server.js
vueRenderer
packages/vue-renderer
ssr.js
createRenderer
createBundleRenderer
vue-server-renderer
終わりゆく Vue 2.x 時代の状態設計の答えと Vue 3 の Provider への期待
Vue 2.x 時代のアプリケーションの課題
Vuexを使わない
求めていたものが多すぎた
ローカルステート or Store以外の選択肢を考慮できない
なんでもそこに突っ込まれる
使い分けるべきだった
API
HTTPキャッシュ、インメモリ
モーダルフラグ
portal-vue
Teleport
ログインユーザー
Storeは使いたい
共通の呼び出し元を用意したい
リアクティブにコンポーネント間のデータ共有
ページ遷移しても保持したい
外部リソースとのテスト
個人の結論
Injectを使用する
thisに生える依存をDIできる
例：this.$axios
メリット
グローバルで露出する状態を最小に
オンメモリキャッシュだけが載った頻繁に叩くAPI
vue/types/vueの一般的拡張の範囲で取り扱える
ユーザー定義であることは変わりない
コンポーエントをクリーンかつテスタブルに取り回しやすい
mocksが利用できる
Provide / injectはVue2.xから使える
Vue3.xからはアクセスしやすくなる
Compostion APIと合わせて使いやすくなる