背筋を伸ばしてスタートアップするブログ

株式会社ペライチで開発責任者をやっています。

「Vue Fes Japan 2018」で最新のVue.js動向を学んできた

f:id:katsuki1207:20181103185801j:plain

Vue.jsの公式カンファレンス、「Vue Fes Japan 2018」に参加してきました。

今期から公私共にフロントエンドの技術動向から目をそむけずキャッチアップしていく方針にしたので参加しましたが、大変勉強になりました。

キーノートセッション

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

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

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

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

WebComponentsとVue.jsのこれから

  • セッション概要
    • Vue.js と Web Components の関係を整理し、両者がこれからどのように関わっていくべきかについて
  • WebComponentsとは
    • カプセル化されたコンポーネントの再利用を可能にするブラウザのAPI群のこと。現在仕様策定が進んでいる。
    • 参考
  • 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に任せることで負債を減らすことができる
  • おすすめのインプット元

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

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

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

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

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

  • 移行のモチベーション
    • 開発開始時はAngular.jsを選択
      • UIが複雑なため2-way bindingが魅力的
      • サーバーサイドはAPI専念
      • エンジニアの採用目的
    • 課題
      • 初期表示速度の遅さ
      • Angular.js1系はSSRをサポートしていない
      • Railsの上に乗ったフロントエンド
  • 表示速度は正義
    • 日経やdev.to
  • 経営視点でのフルリニューアル

  • 技術要件の洗い出し

    • SSRサポートあり
    • 学習/運用コスト
      • デザイナーへの配慮
      • がちのフロントエンジニアじゃなくてもメンテナブル
      • コミュニティの活発さ
  • Vue.jsを採用した理由

    • 実行速度と開発効率の両立
      • SSRのサポート
    • 学習コストの低さ
      • templateがHTMLで書ける
    • ドキュメントの充実度
      • 公式ドキュメント見ればだいたい解決
    • コミュニティの活発度
      • 情報量が多い
    • Vue.jsのエキスパートがコンサルに入ってくれた
  • Nuxt.js採用の理由
    • 規約が手に入る
      • SSRが簡単になる
    • モダンな環境が手に入る
      • Vue.jsのエコシステムをビルトイン
  • 移行手順
    • ページごとにパスベースでロードバランサーにより振り分け
  • 苦労ポイント
    • 並行して現行版(Angular)はメンテしている
  • Lighthouseでのパフォーマンス評価
  • AtomicDesign
  • インフラ
    • 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のテスト)は最高
    • 副次効果としてレビューの負荷が軽減される。でかい。

フロントエンドのテスト方法はちょうど知りたかったテーマなので非常に参考になった。StorybookとReg-Suitの組み合わせは最強に便利そうなので試してみたい。

まとめ

Vue.jsだけでなく、フロントエンドまわりで知らなかった技術の話を沢山聞けて収穫の多い一日でした。フロントエンドFWとして既にかなり盛り上がってるVue.jsですが、今後ますます盛り上がっていきそうな予感です。