雑食日誌

Vue.jsとServerless。ときどきチーム開発

Vue Fes Japan参加レポート

Vue.js JavaScript

日本初のVueカンファレンスVue Fes Japanに参加してきました。 実業務でのお話やVueのこれからのようなコアな話まで聞けたので、レポートにまとめたいと思います。

キーノート

Evan氏によるVue3.0の展望についてでした。 主に以下の変更が加えられます。

  • メモリ使用量低下による高速化
  • ビルドファイルの軽量化
  • メンテナンスしやすさの向上
  • Hooks API

何点か気になった話を書いていきます。
ビルドファイルの軽量化ではTree Shakingが出てきました。 使われていない v-if やv-model などをバンドルせずにビルドできるそうです。

メンテナンスのしやすさではデバッグ機能の追加がありました。
Devtoolの確認に加えて、イベントなどのブレークポイントを見れるようになるのはでかいですね。

Hooks APIはReactで出てきた機能らしいです。アフターパーティーで詳しく聞けました。
ストア管理するほどでもない状態を楽にできるそうなので、Reactを触って先に体験したいですね。

勉強不足で多くを理解できなかったですが、復習して3.0を待ちたいと思います。

ランチセッション

LINEさん

ランチセッション一発目はLINEさんでした アプリだけではなく、クーポンやスタンプのページはVueで開発されているようです。 新規開発もNuxtやVueを用いて開発されてるみたいですねー。

ブースではVueのクイズに答えると抽選でVue.js入門をゲットできる催しをやってました。 抽選は逃してしまいましたが、面白い企画でした。

Scouterさん

NuxtMeetUpでおなじみのScouterさんの発表でした。 みなさんだいたい2014年のVueがメジャーバージョンになる前から使い始めてますね。 Scouterさんはエンジニア10名で継続的にプロダクトをローンチしていてすごいです。

Reproさん

ラストは普段もくもく会でお世話になっているReproさんのセッションでした。 最初はjQueryで開発されていたものをVueで書き換えたということでした。 jQueryからの移行しやすさはVueの魅力の一つなのかなと思いました。

セッション

Vue.js と Web Components のこれから

speakerdeck.com

WebComponents(以下WC)とVueとの共存についてのセッションでした。 WCのメリットは以下のようです。

デメリットは以下

  • 属性値にstringしか渡せない
  • 外部からのイベントハンドリングが難しい
  • CSS設計方法が大きく変わる

Vue CLI3はWCへのbuildをサポートしているためビルド時にtargetオプションをつけることで動かせます。(参考)

$ vue-cli-service build --target wc --name element ./src/App.vue

そのため、Vueで開発してきたものをWCを用いて描画することが簡単にできます。

WCはWeb標準機能のため、相対的に寿命が長く、激しい変更が少ないことが見込まれます。 いつVueが終わってしまうかという心配事が減ることが期待できますね。

WCはあくまでDOMの可視化にまつわる仕組みなのでアプリケーションフレームワークとしての機能は有していません。
データ管理やイベントなどフレームワークとしてはVueが、UI部分はWCに置き換わるのが今後の展望とのことでした。
WCのデフォルトでマテリアルデザインをサポートし始めたら強いですね。

記法がVueに似ている(VueがWCに着想を得ている)とのことだったので自作アプリにも組み込みたいです。

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

slides.com

デザインと実装に距離ができてしまう問題を解決するツールについてのセッションでした。
デザインとフロントエンドの実装では以下の課題がみられます。

  • デザインファイルと実装で使うツールが異なる
  • デザインと実装の管理が重複する
  • 動的なデザインを考慮しにくい

現在開発されていて、上記課題を解決しようとしているツールには以下があるそうです。

  • vuegg
    • デザインしたものをVueファイルとして出力できる
    • コード上で改修したものをキャンバスに戻せない
  • framer X

そこでkatashinさんはSFCでデザインできるようにするツールを開発中でした。
GitHub - ktsn/vue-designer: Vue component design tool

SFCをプレビューし、ドラッグ&ドロップやインスペクターでデザインを変更します。
変更はSFCのファイルにも反映されて、デザインとSFCファイルの双方向バインディングが実現されていました。
デザイナーにも使ってもらえることを目標にしているので、デザインツールで使えるような機能も考えているようです。

実装はクライアント・サーバ型でできていて、SFCをASTに変換し、WebSocketを通してレンダリングされていました。
クライアント・サーバ型のメリットは以下になるそうです。

パースはvue-eslint-parser, postcss, babelを使っていて、TypeScript対応もあるみたいですね。

一人でパーサーを書いて、WebSocketを使い、デザインツールを追従していることが驚きでした。

今後はコンポーネントカタログの自動生成も考えているそうなので、とても期待しています。

Atomic Design のデザインと実装の狭間

デザイナーとエンジニア間の協業という観点のエモいお話でした。

現在Atomic Designが主流になる中でデザイナーからコンポーネントベースの手法が適応されている背景があります。 コンポーネントベースでデザインする上での難点は以下になっているそうです。

  • 学習コストが高い
  • デザインの自由度が下がる
  • 認識が異なる

コンポーネントはエンジニアの概念のため、デザイナーに適応することは難しいそうです。
例として挙げられていたのは構造化プログラミング vs オブジェクト指向プログラミングでした。
Javaが出てきた当初はスピードなどを槍玉に挙げられて非難されていたが、オブジェクト指向に慣れると、 効率が上がるため現在では主流になっています。
デザインの世界では構造化プログラミング的手法のため、いきなり実践するということは無理とのことです。

そもそもデザイナーとエンジニアは責任が異なります。
デザイナーはインターフェースの価値を高めて、ユーザーに届け、エンジニアは効率を重視し、保守性を高めています。

そんな中での現実的な解決策は以下が挙げられていました。

  • エンジニアがデザインを覚える
  • いい感じのツールを作る(さっきのトークの続きだ…)
  • デザイナーの横でコンポーネントをひたすら写経する

弊社ではエンジニアがコンポーネント化する作業を行なっているので、より良いプロセスを考えていきたいです。

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

speakerdeck.com

SPAからNuxtへ移行したためになるお話でした。

noteは当初Angularで開発されていたようです。
この時の技術選定はAngularのみメジャーバージョンに上がっていることが大きかったようです。

しかし、SPAのみでは以下の課題がありました。

  • 初期表示速度の遅延
  • コーディング規約などの負債

フレームワークを変えてのフルスクラッチは難しいと思います。
noteさんはCEOが技術よりということで理解が得られていました。

Vueを選んだ理由は以下になるそうです。

  • 学習コストの低さ
  • ドキュメントの充実度(日本語が充実)
  • コミュニティの活発度が高い

移行手順はページごとに社内リリースから初めて徐々に本番に移行していくやり方ですね。

  • 既存UIを確実に移行
  • ページごとにURLベースで振り分ける
    • 社内リリース、Dog Fooding、一般公開の順番

設計方針ではVuex + Atomic Designを取り入れていました。
Vueを使って堅牢なシステムを作るときのベストなのかなと思います。

個人的にAtomic Designは分子と有機体の違いがわからなくなりますね…
Vuexの参照は有機体以上にしているそうです。
ルールを明文化して、コードレビューの観点にすることが大事なんだと思いました。

Atomic Designを用いることでコンポーネント数が肥大化し、チームが把握できない問題を解決するためにStory Bookを導入していました。
私自身設定周りで挫折した経験があるのですが、Nuxt2.0になったことで楽になっているそうです。
ストーリーをメンテナンスするのが大変なのと、通信周りのスタブ化が辛いため、対象を原子・分子に絞っていました。

インフラはNuxt on Lambdaの構成でした。
ハマりポイントは mya-akeさんのブログで解消できるそうです。

インフラ管理のコストやスケーリングを考えると良さそうですね。
以下の欠点を超えられれば使いたいです。

  • NodeのバージョンがLambdaに依存する
  • デプロイできる容量が決まっている

これまでの移行プロジェクトはnoteのなかでまとまっています。 note.mu

Nuxtの導入を考えているのでとても参考になりました。

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

speakerdeck.com

ラストはコンポーネントテストのお話でした。
コンポーネントの何をどこまでテストするかはいつも悩むのでノウハウを聞けてよかったです。

単体テストを自動化するのは外部からみた振る舞いをテストしていました。
「外部からみた振る舞い」は何かしらのインプットに対してアウトプットが期待とおりかチェックすることです。

コンポーネントの場合のインプットは

これに対してアウトプットは

  • HTML, CSS
  • Event
  • Storeのアクション

にまとめられていました。

Lifecycleでは必要なデータを取得するぐらいなので優先度は低いそうです。
他のテストに影響が出るので、場合によってはモックしてもよさそうですね。

PropsやStoreはスナップショットテストを用いていました。
コード修正の前後の差分を確認し、期待通りであればUpdateする機能です。
今まで使いこなせていない機能なので活用したいと思います。

文字列だけではなくCSSのテストをVisual Testにて行なっていました。
スナップショットテストの応用で画像を取得して差分を出力する仕組みです。
CIに組み込むことで、レビュー観点の一つになるため、レビュワーの負担が軽減するのが良さげです。
レビュワーがチェックアウトしてビルド・確認をする手間が省けるのは大きいですね。

ツールはStorybookとreg-suitoを用いていました。

User Interfaceのテストも同様にVisual Testを使っていました。
テスト範囲はクリックとinputイベントに絞っていて、難しいテストは実施しない選択を取っているそうです。

変更に強くするためのテストであることを忘れずに自分のプロジェクトに適応していきたいです。

まとめ

フロントエンドのカンファレンス自体初めてでしたがとても内容の濃い1日でした。
実践的なお話をたくさん聞けたので、どんどん投入していきたいと思います。
スタッフの方々本当にありがとうございました。