キーノートセッション

docs.google.com

セッション概要
- Vue.js作者EvanYou氏によるVue3.0のアップデート内容について
Vue 3.0はメモリ使用量が減り初期化が高速に
Vue.js3の新コアのランタイムはgzipで10KB以下
Tree shakingに対応
カスタムレンダラAPI
リアクティビティAPI
TSXが使えるように
- TypeScriptで書きやすくなる
experimental) HooksAPI
- mixinのだめなところをhooksでなんとかする
- 詳しくはReactのDan氏のプレゼンを参照のこと
experimental) TimeSlicing
- Reactの新機能「Time Slicing」と「Suspense」をFacebookが紹介。非同期レンダリングを活用しUXをサクサクに向上－ Publickey
- レンダリングに字kながかかる処理、通常固まる。TimeSlicingを使えば固まらない
- 同じ処理が連続したらその前の処理をスキップして高速化できる感じ。

Vue2.xからVue3にかけてかなりパフォーマンス向上していて凄く期待できそう。特にTimeSlicingはUX的観点からもインパクトの大きく、これから導入検討するならVue3から入れたいと思った。

事前知識不足で理解が追いつかない部分がいくつかあったので予習しておくべきだったと少し公開。

以下はイベントとは直接関係ない記事ですが、参考までに貼っておきます。 qiita.com

WebComponentsとVue.jsのこれから

セッション概要
- Vue.js と Web Components の関係を整理し、両者がこれからどのように関わっていくべきかについて
WebComponentsとは
- カプセル化されたコンポーネントの再利用を可能にするブラウザのAPI群のこと。現在仕様策定が進んでいる。
- 参考
  - developer.mozilla.org
WebComponentsの技術
- CustomElements
- Shadow Dom
  - DOMのカプセル化を実現するための仕様
  - グローバルのCSSやJSはShadowDOMに影響しない
- HTML Template
  - もう使われない感じ
  - 要素を使用しHTMLドキュメントでHTMLの雛形を扱うための仕様
- ES Modules
  - これを使ってWebComponentsをインポートする
  - HTML Imports
    - ES Modulesの仕様が安定しブラウザ実装が出揃ったため非推奨になった。Chromeからも削除される予定
- HTML Modules
  - HTMLをJSの中に直接Importできるようにする仕様
  - まだGitHubのIssueで議論されている段階
どうやってVue.jsでWebComponentsを作るか
- VueCLI3 Build Targets
  - Vue CLI 3でbuildするときに —target wc というオプションをつけると、Vue.jsのコンポーネントをWebComponentsに変換してビルドされる
  - Vueコンポーネントをラップしてカスタム要素として登録する
WebComponentsをなぜ利用するか
- 1 . UIの使い回しが容易
  - フレームワークを途中で変えてもUIに影響がない
- 2 . Fully Scoped
  - 大きいプロジェクトでCSSの依存関係がわからないような場合に、グローバルなCSSに影響されない実装がしやすい
  - Shadow DOMを使えばよい
- 3 . Micro Frontends
  - フロントエンドを独立した機能の集合体という考え方
デメリット
- 属性値にString型しか渡せない
- 外部から渡されるイベントのハンドリングが難しい
- Dom要素の取り回しが面倒
- CSSの設計を大幅に見直す必要がある
フレームワークの問題
- いつメンテナンスが止まっていつ実装が止まるかわからない
- Vue.jsに依存し続けるのは危険
- 大きいサービスだと数百コンポーネントあるのが普通
- それ、FWを移行するときにめちゃくちゃな負債になる
- WebComponentsであれば、Web標準なため使い続けられる
Vue.jsとWebComponentsの関わり合い
- Vue.jsはアプリケーションをつくるもの、WebComponentsはUIのためのもの
- 上流のデータ構造の管理やデータバインディングはVue.jsが担って、WebComponentsはその末端として入ってくるようなイメージが濃厚
- WebComponentsはHTML要素をカプセル化して可視化するものであって、アプリケーションを作るためのものではない。
まとめ
- WebComponentsはもう使えるけど課題も多い。
- UIをWebComponentsに任せることで負債を減らすことができる
おすすめのインプット元
- W3Cドキュメント
- よくわかるWeb Components
  - 作者: 泉水翔吾
  - 発売日: 2018/10/07
  - メディア: Kindle版
  - この商品を含むブログを見る

FWに依存しない標準化された技術を使おうという考えはとても共感。特定の技術にロックインされるリスクは特にトレンドの盛衰が激しいフロントエンド技術こそ意識すべきな気がする。

Vue Designer: デザインと実装の統合

セッション概要
- デザインと実装を統合させたツール、VueDesignerの話
  - https://github.com/ktsn/vue-designer
デザイナーと開発者でそれぞれの業務が複雑化しだんだんと役割分担されてきた
役割分担により生じる問題
- デザインファイルと実装でファイルが違う
- ちょっとした変更に対して煩雑な管理が必要になる
  - デザインデータから実装して、デザインするまでもない機能追加の時にデザインデータと乖離が起きて、さらにデザインが必要な機能追加があったときに死ぬ
既存プロダクト
- vuegg
  - プロトタイピング
  - https://github.com/vuegg
- Framer X
  - https://framer.com/
ほしいツール
- SFCが実装かつデザイン
- 長期開発、運用に使える
- 動的にデザインできる
Chrome の DevTool 上で style いじってそれをコピペでエディタに戻すみたいなことがやる必要なくしたい
目標
- まずは開発者が便利に使えるツールに
- 将来的にはデザイナーも使えるツールに

エンジニア視点で見ると便利そうなツールなのと、完成すればVue.jsの学習にも使えそうだと思いました。

noteをNuxt.jsで再構築した話

移行のモチベーション
- 開発開始時はAngular.jsを選択
  - UIが複雑なため2-way bindingが魅力的
  - サーバーサイドはAPI専念
  - エンジニアの採用目的
- 課題
  - 初期表示速度の遅さ
  - Angular.js１系はSSRをサポートしていない
  - Railsの上に乗ったフロントエンド
表示速度は正義
- 日経やdev.to
経営視点でのフルリニューアル
技術要件の洗い出し
- SSRサポートあり
- 学習/運用コスト
  - デザイナーへの配慮
  - がちのフロントエンジニアじゃなくてもメンテナブル
  - コミュニティの活発さ
Vue.jsを採用した理由
- 実行速度と開発効率の両立
  - SSRのサポート
- 学習コストの低さ
  - templateがHTMLで書ける
- ドキュメントの充実度
  - 公式ドキュメント見ればだいたい解決
- コミュニティの活発度
  - 情報量が多い
- Vue.jsのエキスパートがコンサルに入ってくれた
Nuxt.js採用の理由
- 規約が手に入る
  - SSRが簡単になる
- モダンな環境が手に入る
  - Vue.jsのエコシステムをビルトイン
移行手順
- ページごとにパスベースでロードバランサーにより振り分け
苦労ポイント
- 並行して現行版（Angular）はメンテしている
Lighthouseでのパフォーマンス評価
AtomicDesign
- 参考
  - https://medium.com/@t_sugawara/vue-js-%E3%81%8B%E3%82%89%E3%81%BF%E3%81%9F-atomicdesign-e90517842801
インフラ
- LambdaでNuxt.jsを動かしている
  - 構成管理やデプロイを担う
まとめ
- パスベースで小さく移行するのが有効
- SSRの導入はすごく簡単でおすすめ

1年間単体テストを書き続けた現場から送るVueComponentのテスト

セッション概要
- Vueで楽にComponentのテストを書けるように現場でやっていること
ペパボでは半分以上のサービスでVue.jsを使っている
テストを書いてない人の声
- UIは変更が発生しやすい
何をテストするか
- 外部からみた振る舞いをテストする
Componentでいうと
- Trigger
  - Lifecycle, Props, VuexState, UserInteraction
- Output
  - HTML, CSS, Event, VuexAction
mount vs shallowmount
- 基本的にmount
- 設計の可動域を確保するため
Props/Vuex Stateのテスト
- 主に見た目に関わる箇所
- 単純なassertになりがちだけどツラミがたまる
  - 表示が変わったらテストも直す必要
  - ざっくりしすぎ
- いい感じにやるには？
  - Snapshot Testing
  - Jestの機能
  - componentのDOM（Snapshot）を比較
- CSSもいい感じにテストするには
  - Visual Testing
  - Snapshot Testingの画像版
  - 画像の差分検出ツールがあらたに必要
  - さいきょうのVisual Testingの方法
    - StorybookとREG-Suit
User Interactionのテスト
- 重要なFormだけでもやっておくといい
- それ以外は難易度高いので諦めも肝心
  - ややこしいテストはしないという割り切り
- User Interaction後のスクショをとってVisualTestingはすごい便利
結論 -Visual Test（HTML/CSSのテスト）は最高
- 副次効果としてレビューの負荷が軽減される。でかい。