aratana Tech blog

ECテクノロジーで 世界をもっと楽しく もっと笑顔に

Vue Fes Japan 2018 に参加してきました

こんにちは！　クリエイティブグループ所属フロントエンドエンジニアの菊地宏之です。

2018年11月3日に秋葉原UDXで開催された日本初のVueカンファレンス「Vue Fes Japan 2018」に参加してきました。
私の参加したセッションについて、簡単に内容を紹介したいと思います。

キーノート

Vue.js 作者である Evan氏によるキーノートがありました。

https://docs.google.com/presentation/d/1pbNnBhkc-CwfzSw4sW9Ai7A7uAxLuNwOd4Gd5PMjrSQ/edit

  • Vue 3.0の変更点
    • より早く
    • より小さく
      • Tree Shaking
      • ランタイムのサイズが10KB以下 (gzip)
    • よりネイティブ向けに
      • カスタムレンダラーAPI / リアクティブティAPI
    • より保守しやすく
      • TSXによるTypeScriptのサポート強化
      • 警告トレースの改善
    • その他
      • Hooks API
      • Time Slicing

など

感想

要所要所で実演もあり、見た限りでも処理の高速化を体感できました。

Vue.js自体のパフォーマンス改善が大きくなされている印象でした。後方互換も保っているので、基本的に開発者は意識する必要がないとのこと。新規機能も魅力的で早く試してみたいと思いました。

Platinum スポンサーセッション

セッション内では詳細は触れられておりませんでしたが、膨大な量のコンポーネント（650個）を管理しているようで、その手法など非常に興味が湧きました。

セッション

午後からは、国内外の著名スピーカーによるセッションでした。

会場Aと会場Bのどちらかのセッションを選択する方式です。

タイムテーブル

　 会場A 会場B
1 Sarah Drasner
Next-level Vue Animations 		Takanori Oki
Vue.js と Web Components のこれから
2 katashin
Vue Designer: デザインと実装の統合 		Edd Yerburgh
Unit testing a Vuex store
3 菅原 孝則
Atomic Design のデザインと実装の狭間 		Sébastien Chopin
Nuxt.js 2.0
4 Rahul Kadyan
A deep dive in SFC compilation 		福井 烈
note のフロントエンドを Nuxt.js で再構築した話
5 Guillaume Chau
Vue CLI 3 and its Graphical User Interface 		土屋 和良
1年間単体テストを書き続けた現場から送る Vue Component のテスト

※ スピーカーが発表スライドをアップロードしてくださっているものはリンクを貼っております

どれも魅力的で非常に悩みましたが、実務に関連しそうな下記のセッションに参加しました。

  • 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 Componetsに変換してくれる
    • 単体で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/parser
    • postcss
  • Vueレンダラーの再実装 描画するだけじゃなくて、任意の処理を挟めるようにしたいから再実装している。vue-template-compilerとほぼ同様のこと
    → 大体の機能を実装した
    • エッジケースが多い
    • レンダラーを使う方法を模索したい
      → Vue.js 3.0 でカスタムレンダラーが実装されるため
  • サーバ・クライアント構成
    • 開発当初はVS Codeのwebviewがリッチじゃなかったため、サーバを別に立てている。
      今はVS Codeのwebviewでもできるかもしれないが、そちらに寄せる予定はない。
      → VS Codeにロックインされないように（Atomとかでも将来的には動かせるように） デバッグがしやすいなど、他の利点もある。
  • DevTool on VS Code DevTool上でスタイルを当てたものをコードに戻している人が多い
    → エディターにあったら
  • アイディア

感想

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にロックインされる
      • コールドスタートなどの問題もある

感想

まず、全面刷新に際して経営陣の判断が柔軟だったことにも驚きました。

弊社サービスのaratana gatewayでもNuxt.jsを採用しているシステムがありますが、それ以上にさまざまなノウハウが得られる内容でした。また、Vuexの肥大化という課題やその他の問題点についても、どこも同じなのだと共感しました。

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

  • 何をテストするか
    「外から見た振る舞い」をテストすべき
  • Props / Vuex Stateのテスト
    • Snapshot Testing
      • DOMの変更を比較
    • Visual Testing
      • Storybook + Reg-suit
        • GitHubでPRが立つと差分出力して、問題なければApprove
          → レビュー負荷が下がる
      • Storybook
  • UI Testing
    • 簡単なテストだけ、購入フォームだけでも書く
    • あきらめも肝心、ややこしいテストはしない
  • Q. Reg-suit: コンポーネントの数が多い時、CIでイメージ作成して比較の時間は？
    • A. 実際やってるのは100枚ぐらいしかやってない。すべての実行時間は10分ぐらい。
      体感、スナップショット撮るだけだと早い・比較が時間掛かる
  • Q. Visual Testの方法：どの部分でやるのか、E2Eテストの範疇なのではないか

感想

コンポーネントのどこまでテストをすべきなのか非常に参考になりました。

Visual Testingのフローは素晴らしいです。単純なレビュー負荷軽減だけではなく、レビュアー・レビュイー双方とも心理的に安心感があると思います。 E2Eテストだけではなく、Visual Testingはぜひ導入してみたいと思いました。

まとめ

どのセッションも内容が濃く実践的な内容も多く、たいへん勉強になりました。Vue.js にかかわらず、たくさん知識を得られたと思います。
得られた知識を業務にも反映していきたいと思います！

セッションの動画は後日 YouTube にて公開されるとのことです。ぜひチェックしてみてください。

Vue Fes Japan 2019も楽しみにしております。