プロポーザル

Gridsome は、Vue.js のフレームワークで、高速で、SEO フレンドリーなサイトを作れます。

Gridsome、静的なウェブが得意ですが、もう１つ。GraphQL で豊富な入力を扱います。例えば WordPress、これは多くの運用とノウハウが必要。テーマには相応の WordPress力。

もし WordPress の テーマを、既存のウェブフロントの技術で実現できたら。テーマに Vue.js を使うのではなく、Vue.jsのままに使う方法です。

本セッションでは、Gridsome をベースに、Serverlessr WordPress を活用した、WordPress のサイトをウェブフロントの技術だけで、まったく新しく作り出す方法についてお話します。

WordPress は 全ウェブサイトの 30%超、それを Vue.js ファミリーが全く新しい世界に作りだすお話をします。

大規模開発（2年1000人月Over）でのVue.jsの採用について、工夫した点を共有できればと思います。

・大規模開発でVue.jsを採用した理由
・モジュール分割とディレクトリ構造
・アーキテクチャー設計のポイント
・開発環境とツールを活用したバックエンドエンジニア、オフショアエンジニアの底上げ
・TypeScriptの活用とTypeScript化で使用したライブラリ
・モック化による早期検証

Vue.jsやReact.js、最近ではNuxt.jsを利用したSPA開発は現在では当たり前のものとなっています。
初回ロードが完了すればその後の動作が軽快であるなどの理由で採用され、最近ではPWAによるネイティブに近い体験の実現などが目的となることもしばしばあります。

しかし、本音を言えばSPAの機能面での優位性ではなく、Developer Experienceを目的に採用している場合も多いのではないでしょうか。
フロントエンド開発者には、モダンJavaScriptフレームワークも、モジュールバンドラも、HMRも今やなくてはならない存在ですし、当面SPAが優位な状況は続くでしょう。

一方で、自身が取り巻く技術のバックグラウンドと妥当性を常に意識するのは重要なことです。
例えば、アクセス頻度は多いが滞在時間は短いメディアのようなサイトで起動コストが重いSPAは妥当なのでしょうか。例えば、Universal Applicationにに、複雑な状態管理は求められているのでしょうか。

このセッションでは、なぜ私達がSPAで開発するのかを、今あらためて言語化してみます。

近年盛り上がりを見せているPWA(Progressive Web App)ですが、Nuxt.jsにはPWA ModuleというPWAを実装するためのモジュールがあります。
このモジュールを使えば簡単にPWAを実現することができますが、簡単すぎるためにどんなことをしているのか理解して利用している人は多くないように感じます。

今後、PWA開発の需要や事例が増えていく中で、PWAに関する理解や知識は、更に必要なスキルになっていきます。

個人でNuxt.jsを使い何本かPWA開発をして得た経験とスキル、PWAのコミュニティ運営をして得た知見を元に、以下のようなことを紹介できればと考えています。

• PWAの現状とこれから
• Nuxt PWA Moduleを通して見る、PWA開発に必要な実装
• Nuxt PWA Moduleをカスタマイズしていく手法
• 導入事例とカスタマイズ例

PayPayモール（※1）というECにて、将来的なAMPキャッシュ（主にトップ, 製品ページ）を見据えてAMPコンポーネントをVueコンポーネントの上に乗せてコンポーネントを実装した。
それをNuxt hooksのgenerateを拡張し、AMPValidatorに通る形でスタイルやスクリプトを最適化させてテンプレート（※2）を生成している。
単純なamp-imgのみならず、amp-list, amp-carousel, amp-stateやamp-lightboxといったAMPでサービスを作る上で重要なコンポーネントもVueに乗せてエコシステム化している。

Hooks拡張のNuxt（Vueコンポーネント）とAMPコンポーネントの親和性の高さ、
細かな手法や設計、実装のTipsなどについても事例をご紹介できたらと思います

「STUDIO」はコード書かないでWebサイトを作れるデザインツールです。（もちろんVue.js製！）
別の視点から見るとGUIでコードを生成するジェネレータでもあります。

これまで静的なWebサイトしか作れなかったSTUDIOが、今年に入ってから動的なものを作れるように開発を進めています。
この時重要になってくるのがVue.jsやReactなど昨今のフロントエンド開発で登場する「Component」の概念の可視化（GUI化）でした。
また、GUI化によってVue.jsとReactのComponentの設計思想の違いが見える形で現れてきました。

「Component」のGUI化を通じて見えてきた知見を中心に、
実際にデモをしながら新しいデザインプロセスの提案もしようと考えています。

2019年10月1日、日本では消費税の軽減税率が実施され、
多くの金額を取り扱うサービスが影響を受けることになります。

とある請求書の発行・管理サービスにて、コアとなる金額計算のフロントエンドコードは、
グローバル依存かつDOM依存も強く「魔境」と化しており、誰も触れたくない状態でした。
そんな中、軽減税率対応のために大幅な改修が必要となり、
並行して機能開発が進むことを考慮するとVue.jsへの置き換えが必要であると判断しました。

ゼロからのVue.jsアプリケーションの構築であれば、書籍やWeb等で参考となる貴重な情報を多く存在しますが、
すでに稼働している環境への導入ノウハウはあまり存在しません。

軽減税率対応を乗り切った経験から、本セッションでは次のような内容をご紹介できればと思います。

• リスクの高いレガシーコードをいかにして段階的にVue.jsに置き換えたか
• 置き換え時に安全を確保するために何をしたか
• 並行する機能開発への影響をどう抑えるか
• 得られた学びやノウハウ・今後の展望

概要
私はこれまで教わったデザインフレームワークやプラクティスをそのまま現場に適応しようすることが多かったです。
これはフロントエンド開発に限らずアジャイル開発やインフラ設計など普遍的な問題でした。
今回は私がVue.js & Atomic Designをフレーム通りにそのまま導入、実践をしてどう失敗したのかとそこから得られた学びを発表します。
さらにAtomic Designを発展させて、プロダクトやチーム・Vue.jsに適応させた例を共有していきます。

TL;DR

• 思考を停止してAtomicDesignを導入した結果の発表
  　- ロジックの集中、コンポーネントの量産
• 導入するときは現場との差分(Vue.js, チーム、プロダクトの性質 etc..)を考えて追加する
• 視座をプロダクトのレベルまで高めて、設計判断をする
• 改めてVue.js & Atomic Designベースでコンポーネント開発を実践した時に考えたこと
  　- ドメインを持たせたコンポーネントの組み合わせ
  　- ロジックをリポジトリパターンで組み直す

AWS Amplify は開発フレームワークおよび開発者用サービスで構成されており、WebアプリやモバイルアプリをAWS上に簡単に構築する方法を提供しています。
Vueのコンポーネントも提供されており、少量のコードを書くだけで煩雑な手順から解放され、Vue.jsで素早くWebアプリを構築することができます。

しかし、提供されているコンポーネントだけでは実現できないことや、つらい点もいくつかあり、カスタマイズする場面に遭遇しました。
今回のセッションでは、Vue.jsとAWS Amplifyで構築したことを松竹梅の構成について得た知見をお話し致します。

• AWS Amplifyでできること
• aws-amplify-vueコンポーネントで構築
• aws-amplifyのAPIで構築
• Vue.jsとAWS Amplifyをカスタマイズして構築
  * 利用してみて感じたことや課題

現在4000万UUを達成したRettyは9年間運用されているサービスです。
当時、JavaScriptはフルjQueryで書かれていました。
フロントエンド改善活動として、ここ数年でサービス運用をしつつ部分Vue.js、Nuxt.jsに移行した軌跡を紹介できればと思います。

具体的には 部分Vueを運用に乗せ、拡充
jQueryコードやgulp/webpackとの格闘
Jest導入からSEO要件、
アーキテクチャ刷新によりNuxt.jsを導入、拡充していくまでのお話や
施策との相性やログ機構などです。

・jQuery
・Backbone.js
・React, Angular
・React, Vue.js
時代とともにフロントエンドの移り変わりがあるなか
RettyはどのタイミングでjQueryから移行し、
どう運用しているのかをご説明できればと思います。

Vue.jsの人気が高まっていく中で、アプリケーション作るツールとしてではなく、ウェブサイトを作るツールとして使われることも多くなってきました。その中でも静的ファイルを事前に生成しておくプリレンダリングというアプローチを用いると、Vueの知識で開発者体験の恩恵を受けつつ、サーバー不要でサイトを簡単に配信することができます。

プリレンダリングを行うフレームワークとして選択肢にNuxt.jsのプリレンダリングモード、Gridsome、VuePressが挙げられます。これらのフレームワークを選ぶ際には、データの特徴、テーマの利用、再利用性、高速化、メンテナンス性がポイントになります。これらのポイントと噛み合うシチュエーションで適切なフレームワークを選ぶだけで素晴らしい生産性が得られます。
これらの特徴を理解することで、フレームワークを最大限に活かしたアプリケーション開発が可能になります。

本セッションでは、前半はプリレンダリングの動作とメリット・デメリットについて、後半はフレームワーク選定戦略についてお話します。

2017年、私は初めて「vue-test-utils」を使用しました。その時はavoriazというvue-test-utilsの前身のライブラリからの移行期で当然の如くbetaバージョンでした。
時を経て2019年、vue-test-utilsはVue.js公式テスティングライブラリということもあり、Vue.jsを使用しているプロジェクトではデファクトスタンダートと言っても過言ではない状況だと思います。

しかしvue-test-utilsは未だに正式リリースを迎えておらず、betaバージョンのままです。
一体何がvue-test-utilsの正式リリースを阻んでいるのでしょうか？

本セッションでは、vue-test-utilsが抱える問題点以下2つと、それらを解決するために現在検討されているアプローチについて述べたいと思います。

• 継承コンポーネント問題
• vue-test-utilsの同期設定

• コンポーネントを小さく作れば良い！
• Vuexと単体テストを用意しましょう！
• 堅牢な設計でコードをリファクタリングしよう！

果たしてこれらの言葉に本当に従って良いのでしょうか？

フロントエンド開発の中心はデザイナーだ。多くの場合においてどんなデザイナーがどんなデザイン手法を好んで使うのかがフロントエンドのコードのライフサイクル、書き方を決定する最も重要な要素である。
Vue.jsも例外ではない。
私が設計を学び、複数のデザインナー、プロジェクトでVue.js開発に携わり発見したVueにおけるコード設計の極意をシェアし、Vue.js開発が成功する為の力になります。

Vue.js のみならず、Nuxt.js でコア機能として存在する Vuex。Vue.js アプリケーションに TypeScript を導入するにあたり、Vuex の型定義は誰しもが悩んできた課題です。vuex-module-decorators などによるアプローチもありますが、TypeScript の機能をフル活用すれば、純粋な Vuex であっても、隅々まで TypeScript に最適化することが可能です。これは、既存のVuexコードを TypeScript 化することはもちろん、デコレーターを利用したくないシーンで役にたつ TIPS です。2019年6月に刊行するTypeScript 商業誌に綴った、その手法の全容を紹介します。

管理画面のような複雑なバリデーション機能などをフロントエンドで実現しなければならない時、そのテストはどのように実施するでしょうか？
私達はこれまで、単体テストはもちろん、E2Eテストや画像回帰テストなどを実施してきました。
しかし、プロジェクト内での認識齟齬が原因で「なぜもっと前の工程で問題を見つけられなかったのか？」と思うことが何度もありました。

この課題に対して、私達は「The Testing Trophy」を意識したテスト戦略を整理し「vue-testing-library」を導入した結果、フロントエンド開発の品質向上に貢献することができました。
セッションでは、具体的にこれらのツールをどのように開発フローに装着し、開発プロセスを改善していったのかをお話できればと思います。

• The Testing Trophy と Waterfall model
• Testing Library による Integration Test