はじめに
2023/10/28 に東京都中野で開催された Vue Fes Japan 2023 に参加してきたので、レポート記事を書いてみようと思います。
今年の Vue Fes はコロナ禍以降初となるオフライン開催で、前回はなんと 2018 年だったようです。
（2019 年はコロナ禍以前ですが、運悪く台風と重なってしまって中止になっていたようです。）
このレポートでは、各発表の詳細というよりも、全体を通して感じたことを中心に書いていきます。
各発表の資料は下記にできる限りまとめてみたので、ぜひご覧になって見てください。
発表者の方々のアカウントをフォローしたり、いいねをしたりして応援していきましょう！
近いサポート終了 - 各社のマイグレーションとの戦い
今回の発表のうち、最も多かったテーマは Vue3 / Nuxt3 へのマイグレーションについてでした。
Vue2 は 2023年12月末、Nuxt2 は 2024年6月末でサポートが終了するため、多くの会社がマイグレーションに取り掛かっているようです。
印象的だったのはみゅーとん氏による発表です。
1000 以上のコンポーネントを漸進的に移行するために、気づいたらマイクロフロントエンドのフレームワークを開発して OSS として公開していたというパンチのある内容でした。
あまりに巨大すぎるリポジトリゆえ、ビッグバンリリースが不可能と判断し、この様な手法を採用するに至ったようです。
既存の重厚なフレームワークよりも手軽に使えそうなので、移行するプロダクトの性質次第ではかなり有効活用できそうだと感じました。
肝心の移行については、これから実施していくとのことなので、今後どの様に進んでいくか、結果が楽しみです。
他の発表でも多くのマイグレーション戦略やその背景が共有されていました。
これからマイグレーションに本格的に取り掛かる私としては、この点だけとっても参加して良かったなと思える内容でした。
Vue3 以降のマイグレーションはどうなるか
Vue の開発コアメンバーによる発表では、Vue2 → Vue3 のマイグレーションだけでなく、更にその先のマイグレーションについて触れられる回数も多かったように感じました。
やはり Vue2 → Vue3 の破壊的変更でユーザが離れてしまったことに危機感を感じていたのか、Vue3 や Nxut3 ではそうならないように対策をしている、ということを繰り返していました。
また、Vue や Nuxt 本体の互換性だけでなく、エコシステムの互換性の問題もマイグレーションを困難にしている要因と認識しており、Nuxt ではエコシステムの CI を構築するなどして互換性を維持するための対策を講じているようです。
この CI の画面はコアメンバーらの発表で幾度となく登場していました。
UnJS の構築も、こういった取り組みの一貫と言えるかもしれません。
Nuxt のサーバエンジンである Nitro や、その他利用しているツールは、それぞれ Nuxt とは別の独立した UnJS というライブラリ群として開発されています。
CLI を構築するツール、Logger、Config を読み込むツールなど、かなり細分化されており、どれも使い勝手が良さそうな印象でした。
コントリビューターの間口を広げることで、コミュニティを大きくし、互換性維持のためのリソース確保につなげるという狙いもありそうです。
コアメンバー達の本音
最終盤の企画、Vue.js クリニックでは Vue / Nuxt のコアメンバーである
- Evan You (Vue の作者)
- Sebastien Chopin (NuxtLabs CEO)
- Daniel Roe (Nuxt コアチームメンバー)
らに事前募集した質問をぶつけていました。印象的だった質問と回答をいくつか紹介します。
マイグレーションについて
Vue3やNuxt3以降で辛いのはVuetifyが大きな要因のひとつだと思っています。 Vuetifyを利用している中でマイグレーションをする良い方法があれば教えてほしいです。(懇願)
彼らにこの質問をぶつけるか！と思わず笑ってしまいました。
Evan の回答は以下。
Vue2 + Vuetify2 のプロジェクトを Vue3 + Vuetify3 に移行するのは正直辛い。だが、Vue3 より後の移行は後方互換性を大切にしているので、これまでよりも問題なく進められると思う。
公式にVue3 + Vuetify3 に移行するのが辛い作業であることが確定してしまいました。 笑
今からまさにその作業をしようとしていた私は、逆に覚悟が出来てよかったです。銀の弾丸など無い。
ref vs reactive
Vue.js の Reactivity API に関して、 ref と reactive は結局どちらを使うのがいいんでしょうか ? 全部 ref で OK と言っている方をちらほら見かけるのですが、逆に reactive はどのようなケースで使うのが良い感じなのでしょうか ?
Evan の回答は以下。
reactive は ref からも呼ばれている。
reactive の書き味は OptionsAPI とも似ているので当初は推していたが、ユーザーが ref に慣れてきた今となっては ref をオススメしたい。
ただ、reactive を使うメリットもあるので、無くすことはない。
さらに追加の理由として、下記を挙げていました。
- reactive を使うと一つのオブジェクトに全ての state を突っ込んだような実装になりがちのため。
- Options API では this. を使う必要があったので、リアクティブであることがわかりやすい。reactive だと普通の定数なのか、リアクティブな定数なのかが分かりづらい。
Vue3 リリース直後からどちらを使うべきか、意見が分かれる点でしたが、ref を第一に使う、ということで、ついに決着がついたと言えそうです。
デザインパターンについて
主にnuxtの質問になってしまうのですが、component設計について伺いたいです。 atomic DesignやContainer/Presentationalパターンなど有名なものはありますが、nuxtと相性がいいと思える設計があれば教えて欲しいです。（サービスの大きさにもよると思いますが。）
この質問に対する Evan の回答が印象的でした。
我々が Vue を使うときにパターンを気にしたことはない。Vue は Angular がパターンを多用しすぎていたことから学び、シンプルに実装できるようにしている。
唯一パターンといえるのは composable だけ。
パターンよりは本質的な部分に拘った方が良い。
そう、Evan 自身は特定のパターンなど気にしたことはないとのことでした。
確かに Vue は充実したスタイルガイドがありますし、さらに Nuxt は最初から pages/layouts/components ディレクトリが存在します。これくらいのパターンを守っておけば問題ないように設計されている、という事かもしれません。
確かに私自身も ７００ コンポーネント規模のプロジェクトをフラットなディレクトリ構成で扱っていたことがありましたが、大きな問題になったことはほとんどありませんでした。
Sebastian も述べていましたが、複雑なディレクトリ構成は、やりたいことに対して「オーバーキル」であるかもしれません。
下記のスレッドに議事録的にメモを残しておりますので、全容が気になった方はぜひご覧ください。
おわりに
私自身、この規模の技術カンファレンスに参加するのは初めてでしたが、どの講演/企画も非常に興味深く、最初から最後まで退屈する暇などありませんでした。
開発者本人たちの話を存分に聞けたのも良かったですね。
尊敬する Evan You と Anthony Fu に直接感謝を伝えることもできて最高でした。
久しぶりに再開した方もいて嬉しかったです。
今回は個人スポンサーとして参加しましたが、それでもお釣りが来るほど参加する価値があったと感じています。
私がこれまで Vue で稼いできたお給料に比べれば、１万円の個人スポンサー料など安いものです。
来年もまたスポンサーをしようと思っています。みんなもしよう！！
また来年の開催を楽しみにしています。次はスピーカーの実績を解除したいですね！
以上、Vue Fes Japan 2023 参加レポをお送りしました！
最後までお読み頂きありがとうございました！
「よりそう力で世界を変える」 ライフエンディングプラットフォームを構築しています。 エンジニア募集中です。 herp.careers/v1/yorisoinc/requisition-groups/048a2e23-3f4a-4406-9694-f967113beca9
Discussion