2018 年 11 月 3 日に秋葉原 UDX で開催された日本初の Vue カンファレンス「Vue Fes Japan 2018」に参加してきました。
私の参加したセッションについて、簡単に内容を紹介したいと思います。
キーノート
Vue.js 作者である Evan 氏によるキーノートがありました。
- Vue 3.0 の変更点
- より早く
- 仮想 DOM 実装をフルスクラッチから再実装
- Native Proxy による高速化
- コンパイラの仕組みを大幅に変更
- Static Tree Hosting / Static Props Hoisting
- より小さく
- Tree Shaking
- ランタイムのサイズが 10KB 以下 (gzip)
- よりネイティブ向けに
- カスタムレンダラー API / リアクティブティ API
- より保守しやすく
- TSX による TypeScript のサポート強化
- 警告トレースの改善
- その他
など
感想
要所要所で実演もあり、見た限りでも処理の高速化を体感できました。
Vue.js 自体のパフォーマンス改善が大きくなされている印象でした。後方互換も保っているので、基本的に開発者は意識する必要がないとのこと。新規機能も魅力的で早く試してみたいと思いました。
Platinum スポンサーセッション
セッション内では詳細は触れられておりませんでしたが、膨大な量のコンポーネント（650 個）を管理しているようで、その手法など非常に興味が湧きました。
セッション
午後からは、国内外の著名スピーカーによるセッションでした。
会場 A と会場 B のどちらかのセッションを選択する方式です。
タイムテーブル
※ 参加したもの「★」をつけています
※ スピーカーが発表スライドをアップロードしてくださっているものはリンクを貼っております
どれも魅力的で非常に悩みましたが、実務に関連しそうな下記のセッションに参加しました。
- Vue.js と Web Components のこれから
- Vue Designer: デザインと実装の統合
- Atomic Design のデザインと実装の狭間
- note のフロントエンドを Nuxt.js で再構築した話
- 1 年間単体テストを書き続けた現場から送る Vue Component のテスト
Vue.js と Web Components のこれから
- Web Components はモダンブラウザで動く状態になっており、production-ready にある
（※ IE と Edge を除いて） - Vue CLI の build で
-target wc すると Web Components に変換してくれる- 単体で WebComponents として動作する
- Vue.js 分、通常の WebComponents よりはサイズが大きくなってしまう
- Web Components への移行や部分的な導入に使える
- Web Components を使う理由
- UI フレームワークを統一できる（サービス間で使い回すことができる）
- UI 部分を使い回すことができる（React → Vue.js への移行）
- Web Components のデメリット
- 属性が String のみしか渡せない
- 外部からのイベントハンドリングが難しい
- DOM 要素の取り回しが面倒
- CSS 設計見直しが必要
→ 正直、Vue.js の機能を使ってコンポーネントを作ったほうが柔軟、機能的で簡潔
- Micro Frontends という考え方
- フロントエンドを分割して、機能の集合体と捉える
- 柔軟なウェブアプリケーションを作る
- CSS・JS・ライブラリ変更、DOM 構造の変更
- Web Components なら Scoped なので変更が用意
ボタンを変えたかっただけなのに、全体が壊れる…みたいな事は起きない
- Framework migration
- Vue などに依存した実装だとフレームワークが死ぬと負債になる（移行が大変）
- UI の実装を Web Components（ウェブ標準）に移行しておくことで、負債を溜めない
- Vue.js は Web Components に置き換わるのか？
- NO: Vue.js は Web Components と共存していくもの
Web Components はあくまでも HTML をカプセル化するものであって、アプリケーションを作るものではない。逆に Vue.js はウェブアプリケーションを作るものである
感想
Web Components を現状の製品に組み込んでいくのはまだまだ厳しいですが、遠い未来の話ではないと感じました。近い将来を見据えて、ウェブ標準の最新技術を注視はしておく必要があると思います。また、「負債を溜めない」という考え方には大変共感しました。
Vue Designer: デザインと実装の統合
- ウェブアプリ・サイト開発
- デザイン・実装が分かれている
デザインはデザイナー、実装はフロントエンドエンジニアがデザインファイルを見ながら実装を進める（HTML/CSS/JS に落とし込む）
→ 昔はデザイナーが全部やれていたが、今は複雑化してしまっているため分かれているのではないか（デザインだけでも専門性が必要）
- デザインと実装が分かれる問題
- それはそれで専門性があるので良い
→ 良いが、デザインで作ったものを実装する（単純に二度手間） - デザインするまでもない実装はデザインせずに実装してしまう事がある
- デザイン上は静的・大丈夫でもウィンドウ幅が違った時の挙動
- みんなが解決しようとしている
- （katashin 氏が）欲しいツール
- SFC が実装、かつ、デザイン
→ 実装とデザインファイルが同じ - 長期開発、運用に使える
- 動的なデザイン
- Vue Designerを作っている（まだまだプロトタイプ）
- デザインと実装の統合
- データは SFC だけなので余計な差分が生まれない
- SFC の静的解析
それぞれを AST に変換して、WebScoket を通してクライアントに返しているvue-eslint-parser@babel/parserpostcss
- Vue レンダラーの再実装
描画するだけじゃなくて、任意の処理を挟めるようにしたいから再実装している。vue-template-compilerとほぼ同様のこと
→ 大体の機能を実装した- エッジケースが多い
- レンダラーを使う方法を模索したい
→ Vue.js 3.0 でカスタムレンダラーが実装されるため
- サーバ・クライアント構成 - 開発当初は VS Code の webview がリッチじゃなかったため、サーバを別に立てている。
今は VS Code の webview でもできるかもしれないが、そちらに寄せる予定はない。
→ VS Code にロックインされないように（Atom とかでも将来的には動かせるように）
デバッグがしやすいなど、他の利点もある。 - devTool on VS Code
DevTool 上でスタイルを当てたものをコードに戻している人が多い
→ エディターにあったら - アイディア
- デザイナーと開発者が GitHub 上で同じコードを編集
- コンポーネントカタログの自動生成
感想
Vue Designer は、まだまだプロトタイプとしながらも現時点でも実戦投入できるように見えました。
デザイナーとフロントエンドのコミュニケーションコストは課題だと日々実感しています。チーム内では良くも悪くもコミュニケーションがエンジニアとデザイナー同士、活発に行われています。
「デザイン＝実装（デザインと実装の統合）」になれば、デザインから実装への二度手間を完全に無くすことができるようになりますし、コミュニケーションコストも完全になくなります。デザイナーの意図したデザインを表現するためにもこういった仕組みづくり（システム化）が大切だと感じました。
Atomic Design のデザインと実装の狭間
- やりとりで起こっている問題
- コンポーネントが出揃ってさえくれば良い
- コンポーネントの必要性をデザイナーが理解しない
- エンジニアが実装側でコンポーネント化している
- デザイナー間のやり取りが大変になってきた
- 実装を知らないデザイナーには雲をつかむような話
- Atomic Design でどうにかなるのでは？
→ ならない（UI 設計は共有化できるけど） - コンポーネントはそもそもエンジニアリングの概念
（デザイナーにとって今まで関心事ではなかった）- Java（オブジェクト思考の）浸透
→ みんな慣れた - デザインツールにそういうことが起こっている
→ 数年前まではあまり流行ってなかった（コンポーネント思考）
→ 慣れてない - Sketch はデザイナーにとっての Java（Sketch vs Photoshop）
（オブジェクト思考 vs 構造化思考） - ツールのサポートがまだ足りない（デザインとコードをつなぐところが）
- エンジニアは合理化の化身
- デザイナーはエンジニアじゃない
- デザイナーはクリエイティブに集中したい、エンジニアは保守コストを下げたい
→ そもそも職責が違う
→ ただ、フロントエンドの苦しみは上流から変えていかないと改善しない
- Design Ops
→ デザインに集中できるような構成 - Atomic Design だけだとカバーしきれない
- 設計手法だけではカバーできない
→ 手段でカバーする - デザインプロセスをカバーする組織づくり
- エンジニアがデザインツールを覚え、コンポーネント化の手本を示す
- デザインをサポートできるエンジニアリング（Vue Designer のような）
例：デザインからアイコンを自動生成できるようにするとか
- プロトタイプを作って、客に見せながら角度を高めていく
→ 同時に実装コードも書いていく（置いていかれる）
仮説検証も同時に - 仮説検証のサイクルを回していくうちにアプリケーションの実装コンポーネントが一緒にできていく（手探り）
- デザイナーがデザインに集中できるエンジニアリングで助ける
感想
現在進行中の案件に Atomic Design をデザインに組み込んでいる最中なので、非常に興味深い内容でした。コンポーネントの粒度などデザイナーとエンジニアが互いに歩み寄って精度を高めていく必要があると再認識しました。
「デザイナーとエンジニアでペアプロ（デザイン）する」というのはおもしろい試みだと思いました。
note のフロントエンドを Nuxt.js で再構築した話
- もともとは Rails + Angular 1
- Angular, Coffee Script, HAML
- 課題
- 初期表示の遅さ
- 技術的成約
既存技術の延長では解決が困難- Angular 1 は SSR できない
- Rails に乗っかっている
- Angular と Nuxt.js で同時に開発進行している
- Atomic Design
- コンポーネントが多くなり、メンテナンスも大変になり、Storybook も挫折
→ Nuxt.js v2 から Storybook が導入しやすくなり、コンポーネントをきちんと把握できていない不安感もあり導入
- Lambda で配信
- Node.js のバージョンが Lambda にロックインされる
- コールドスタートなどの問題もある
感想
まず、全面刷新に際して経営陣の判断が柔軟だったことにも驚きました。
Nuxt.js を利用してシステム開発の経験もありますが、それ以上にさまざまなノウハウが得られる内容でした。また、Vuex の肥大化という課題やその他の問題点についても、どこも同じなのだと共感しました。
1 年間単体テストを書き続けた現場から送る Vue Component のテスト
- 何をテストするか
「外から見た振る舞い」をテストすべき - Props / Vuex State のテスト
- Snapshot Testing
- Visual Testing
- Storybook + Reg-suit
- GitHub で PR が立つと差分出力して、問題なければ Approve
→ レビュー負荷が下がる
- Storybook
- zisui でスクリーンショットを撮る
- テスト用の汎用的なモック Store を用意
- UI Testing
- 簡単なテストだけ、購入フォームだけでも書く
- あきらめも肝心、ややこしいテストはしない
- Q. Reg-suit: コンポーネントの数が多い時、CI でイメージ作成して比較の時間は？
- A. 実際やってるのは 100 枚ぐらいしかやってない。すべての実行時間は 10 分ぐらい。
体感、スナップショット撮るだけだと早い・比較が時間掛かる
- Q. Visual Test の方法：どの部分でやるのか、E2E テストの範疇なのではないか
- A. E2E やるとエッヂケースの対応が大変、コンポーネント単位の方が簡単
感想
コンポーネントのどこまでテストをすべきなのか非常に参考になりました。
Visual Testing のフローは素晴らしいです。単純なレビュー負荷軽減だけではなく、レビュアー・レビュイー双方とも心理的に安心感があると思います。
E2E テストだけではなく、Visual Testing はぜひ導入してみたいと思いました。
まとめ
どのセッションも内容が濃く実践的な内容も多く、たいへん勉強になりました。Vue.js にかかわらず、たくさん知識を得られたと思います。
得られた知識を業務にも反映していきたいと思います！
セッションの動画は後日 YouTube にて公開されるとのことです。ぜひチェックしてみてください。
Vue Fes Japan 2019 も楽しみにしております。
