00:05
はい、10月24日、月曜日ですね。僕は朝9時を回りました。
寝坊するって言っておきたいんですけど、ちょっとだけ遅れだったので、なんとか許容範囲だと思います。
はい、おはようございます。ひめのけいすくんのくわはらです。
では本日も朝活を始めていきたいと思います。
前回からの続きですね。今日もタイトルのVue2 Vue3 マイグレーション 令和最新 最強の記事ですね。
記事というか、Googleスライドですね。の続きを読んでいこうと思ってます。
前回、昨日ですね、半分まで読み終わりました。意外とこのスライドの枚数が多くてですね。
ざっくり半分ぐらいまで行ったんですけど、今日は改めて区切り的にちょっとだけ戻って、書き換え作業のところから早く戻って喋っていきたいと思います。
はい、では行きましょう。
まず基本戦略ですね。正規表現で漏れなく一括痴漢していくというところがまずスタートでしたね。
ファイル数が多かったので、エラー箇所の修正はなるべく漏れなくパターンマッチさせて見落としを防ぎたいというところですね。
例えばその例としてプロップの型定義でプロップタイプで記述しているところとプロップオプションズを使って記述しているところがあったりするので、
Vue3だとプロップオプションズがなくなっていたからこういうのを正規表現でガッといっぺんにやっていたと。
あとは開業とかスペースの有無に関係なくもいい感じにマッチするよというところですね。
あとは正規表現の例もこんなふうなコードを書いたよというのも載っていますので、参考にしていただければというところですね。
こういうところは本当に人がやっていたら絶対にマンパワーでやるとミスだったり漏れだったり大げげが起きるので、正規表現で一発でやれたというのは結構大きいですね。
あとはコンポジションに寄せていくという話がありましたね。2021年の2月、昨年の2月からやったことです。
Vue3化とコンポジション化はイコールではないんですけど、なるべくコンポジションに揃えたい方が扱いやすいので、人のところはVue3以前から置き換えていたということですね。
Vueは多様な書き方ができるんですけど、時期によっていろいろな書き方をしていたのを統一的にしたいという話も昨日見ました。
そのためオプションズAPI、クラスAPIからコンポジション化するツールを作成したと。
Vueコンポジションコンバーターみたいなのを作ったというところですね。
こういうのを作ったというところがさすがだなというところでした。
ざっくり見ましたけどディフを見る感じで、
タイプスクリプトのプレイグラウンドみたいな感じで左に書いたやつが右にバンとコンバーターされるよというところですね。
セレクトボックスでオプションズAPIとかクラスAPIというところも選択できて、それについての変化もできるようになっているという素晴らしいツールでしたね。
これによってVue3化後にスクリプトセットアップ化もしやすくなったというのが大きいと言っています。
それのサンプルのソースコードですね。
このコンバーターのサンプルソースコードがこのキャプチャーで載っていますよということでした。
あとはセットアップコンテキストとルートというやつですね。
Vue2でコンポジションにしてもユーズストアやユーズルーターが使えないので、
暫定的にセットアップ関数の対応引数のプロパティルートというのをVis代わりに使っていたよということだそうですね。
03:01
これはVue3、もしくはVue2というので廃止になったというところですね。
Vue3化のタイミングでユーズストアに置き換えました。
これも結構インパクトありそうではありますけど、どれくらいの量があるかは予想つかないですけど、
そんな大きくないんじゃないかなという感じがしましたね。
続いて、ストアとルーターのVue3化ですね。
VuxとVueルーターなど公式のライブラリがVue3のバージョンに上げるというところですね。
各ライブラリの定義部分をVue3用に書き換えていったと。
コンポーネント側では先ほど暫定で使っていたコンテキストですね。
ctx.root.$storeという部分を削除して、conststoreイコールユーズストアなどに追加するよというところですね。
はい。いかにも復活感があっていいなというふうな感じです。
ギシ感ありますね。
続いてVue3対応されていないライブラリの問題ですね。
これは結構大きいと思いますけど。
使用ライブラリによってはVue3対応がしていないために移行できないケースもありますと。
一旦動作するように空のオブジェクトとか関数を返すことで対応したと。
まあまあ、ほんと暫定的って感じですね。
まあとにかく動かすことが最優先なんですね。
そりゃそうだよねっていう。
あとからその同等の機能を自分で実装をなんとかしたらと。
なんとか自分で実装したのですか。
それはもうそのままなんか対応したライブラリとかもしあるんだったらVue3化した分は
いろんなライブラリにプルリク出してもらえたらすげー嬉しいしありがたいですけど
そんな金も時間もないし、自分の時間をそのままに使うかっていうところもあったりするので
お金払っていいので、もし対応しているライブラリがあるんだったら
ぜひぜひプルリク出したいぐらいです。
オープンコレクティブとかで普通に投げずにしたいと思いますけどね。
はい、続いて。
あと大型ライブラリの場合は対応が難しいと。
まあさすがにそれはそうですよね。
移行ベルトで段階的に移行作業を進めておいてVue3対応を待つべきかもっていうところでしたね。
まあ大きいライブラリはもうどうしようもならずですね。
さすがに複雑度を増してあり、その中の実装までかかって手をかけるってなると
もうそれ自分で作ったら早くないって感じになる可能性もありますからね。
というところでした。はい。
では続いてコンポーネントテストですね。
コンポーネントテストもある場合だととりあえず大変でしょうと。
おそらく大変ってことは今回のケースの場合はなかったってことですかね。
コンポーネントテストはしなかったってことですかね。
書いてました。
今回のプロジェクトでは関数のユニットテストとE3のみだってところだそうですね。
コンポーネント単位のテストはもともとやってないと。
なのでテスト絡みの話は今回ありませんってことでした。
まあなんとも言えないところですけど
コンポーネント単位のテストってやるやらの話はですね
未だに議論のようじゃいくらでもありまして
フロントエンド界隈でもまだ確定的にやった方がいいとかこうだみたいな
意見があるわけじゃなくて
いろんな勉強会に参加してテストを書いている人のお話聞いたりしますけど
やっぱりやってる人でやってない人のバラバラはありますけど
やってる人の方が僕の中でパッとき印象は強かった
印象というか数が多い印象がありますけど
今どうなんでしょうね。ちょっとわかんないですけど。
まあでもなんですけどいわゆる処理自体を
関数に切り出したというところをテストすることが多くて
コンポーネント単位のテストってやるとしても初期レンダリングか
ちょっとユーザーが操作した後のデータが変更になった
06:01
そのデータがちゃんと反映されてるかみたいなとか
UIが若干色が変わったり形が変わったりするとかあるかもしれないですけど
それぐらいの差でしかなくて
まあそれっていわゆるストーリーブックのスナップショットです
とかでやれば別にいいんじゃないのっていう気もしているので
あんまりコンポーネント単位のテストっていうのは
本来やってないっていう人も話としてはよく聞くなという感じはしますけどね
まあいいや余談でした
では今日のむしろメインのお話である
破壊的変更の話についに入っていこうと思います
わざわざ背景黒で赤文字で破壊的変更っていう
しかもフォントもちょっと選んでる感じがするので
よっぽど大変だったんだろうなっていうのは予想つきますけどね
はいじゃあ行ってきましょう
いろいろあるので環境によって変わるとは思いますが
とりあえずh関数をrender1からではなくて
import h from viewとして使用するようになりましたと
あーはいはいはいそういう感じなんですね
で、Vノードプロプス周りもいろいろ変わったらしいです
登録済コンポーネントを名前で描画するときは
resolveコンポーネントが必要になるようになったと
続いてですね
attribute collisionですね
失礼しました
attribute collision behaviorですね
はい
属性にVルーチをバインドしたときの振る舞いがやっぱり変わったらしいです
view2だと例えばcolon foo equal falseみたいなのだと
属性が出力されなかったんですけど
view3だとfoo equal falseみたいなとしても
そのまま出力されるよってことだそうです
これcolonつけるつけないでも一緒になったってことですか?
んーと?
まあ確かにbreaking changeではあるんですけど
ほんとよ
公式でもcolonついてない場合で
attribute equal falseとかで書いても
表示されてしまうと
これは大きい変更ですね
影響がでかいって意味ですね
view3だとfoo equal falseでもいい
colonつけなくても出力されてしまうというところですね
2だとcolonを頭につけたattributeにしないと
これはviewの変数ですよという風に認識してくれなかったんですよね
ということでもしスタイルで
例えば仮括弧みたいな属性セレクターを使っているときですね
その場合もfalseのときにもマッチしてしまうので
ちゃんと仮括弧equal trueのように修正が必要ですよってことですね
省略的に仮括弧みたいな書き方では今回はもうダメですよってことですね
まあそもそも属性セレクターを使う必要はそもそもないんですけど
使ってしまうところがやっぱりあったので修正対応したというところですね
その他いろいろあるんですけど
他のコンポーネントのライフサイクル関数名がちょっと変更になったりとか
トランジッション用のクラス名が変更になったりなどなどとかですね
あとはeslintで警告が出たり自動フィックスされるところも多かったりして
難しいのはエラーにも警告にもならずに壊れるところの対応がやっぱ大変だったと
これはもうしらみつぶしにやっていくしかないので
画面数とか機能数が多ければ多いほどそれは地道に探していくしかないので
比例して大変になってくるんだろうなってそもそも探すのが大変なので
これはなるほどでしたってことですね
以上で一応破壊転機変更のところは今の以上のところだったそうです
さらっと書いてますし1ページ1ページ簡単に書いてますけど
09:04
かなり地味とろな地道な作業があったんだろうなっていうのは推察されますね
はいっていうところでした
ビュー3のドキュメントの中にブレイキングチェンジのページがあるんですけど
結構項目多いんですねブレイキングが
それは大変でしょうねっていうのと
ブレイキングの項目が多ければ多いほど比例したコンポーネントの数が多いアプリケーションとかは
どんどんどんどん作業工数が上がるのでそうだよねって感じはしました
続いて移行作業でのあれこれってやつですね
実行時のワーニングですねまずは
実行時ワーニングですけどブラウザで実行するとエラーではなくてワーニングが出ることも多い
ちなみにワーニングじゃなくて正しい発音で確かウォーニングでした
今回はワーニングできますけど
ワーニングだからといっても放置はできないよと
開発環境ではOKでもやっぱり結局本番でエラーになったりする可能性が多いにあります
エラー内容が不明瞭なんだけど
ワーニング対象のコンポーネント周りを調べていくと何かしら移行に失敗してることもやっぱあったらしいですね
全然あると思います
あとは細かいハマりとして
ビュー2だと同一コンポーネントでインジェクトとプロバイドしていてもOKだったんですけど
ビュー3ではエラーが発生してなかなか原因がわからんかったというところですね
そもそも同一コンポーネントするべきじゃないっていうので書き方が良くないっていうのも確かにおっしゃる通りですね
同じコンポーネントインジェクトとプロバイドは良くないと僕は思います
けどビュー3だと結構許されてしまう書き方がやっぱあったんですよね
そういう細かいところがビュー3かでまともになってエラーになってハマる場合がある
今まで吉野にできてしまっていたところに依存してしまったっていう書き方がやっぱよろしくなかった
気持ちはすごくわかります
やりたいことを実現するようになって
どう考えても良くないんだけど使えるんだから使っちゃおうは
エンジンなどしてやりがちですよね
あとからブレーティングチェンジをするときにハマるっていうのもその通りなので
ちゃんと未来予測をして今時間かけるか未来に時間を任すかっていうところですね
今回は未来に任せて実際にハマったっていうところですね
続いてコンフリクト対応だそうです
作業が長期化すると開発ブランチがどんどん進んでいきます
定期的にブランチを取り込むたびにコンフリクト解決が大変だと
まあそうよね影響範囲が大きいんだからみんなが触ってたらいろんなところなんだかんだ被ってコンフリクトワーってなるのは
本当によくある話になる気がしますので
まあ大変ですよねこれ規模が大きいアプリであればあるほど
むしろコンフリクト対応の方が大変だったんじゃないかって僕はちょっと予想しますけどねこれは
あのブレーキングチェンジよりもですね
でコンフリクト解消したことでビュー2に戻ってしまった分もう一度ビュー3化しなきゃいけなかったりするとそういうニュースですね
二度手間が発生するとか全然あり得るし先祖帰りするなんて絶対あると思いますので
で結果的にまあそういう先祖帰りだったりコンフリクト対応してたら
自分の担当する以外のブレーキングチェンジだったりそのビュー3対応をずっとやらなきゃいけないので
12:02
結果的にメンバー全員がビュー3の全部の対応とか変更点にどんどん知識が深くなっていくような気はしますけどね
まあそういう意味ではいいかもしれないですけど
いずれ失われる知識なのでこれをみんなが今インストールするっていうのを考えると
なんかビジネスインパクト的にはあんまり嬉しくないなって感じですね
はいはいまあとにかくとても辛いっていう一言が書いてあって
まあもう慎重を差しいたしますって感じでした
で移行作業が長引くほど辛くなるので早めに終わらせたいよってところですね
これも本当そうですね
で最終局面です
まあこの辺はもう多分メンバーみんな参加してるっておっしゃっていたので
まあこの辺は結構大変だったんだろうなと思いますが
大体全機能がビュー3で動くようになったところで開発ブランチについにマージをしたと
で1週間ほどリリースを止めて全員で動作確認修正を行った
いい話
リリース後にもやっぱり細かいスタイルの崩れとか動作不良もあったはあったんですけど
まあとにかく見つけ次第すぐに直すことでとりあえず何とかしたと
この辺はもう本当に頑張ったということですね
でこの記事のラストですね
ビュー3化してどうだったかというところですけど
まず良かったところですね
スクリプトセットアップ1本だけになってやっぱりそれは楽になっているところだそうです
あとやっぱり実行パフォーマンスが良くなったっていうのも本当に大きいところだそうですね
前言ってましたね
まずビート化したところとあとビュー3化したところで合計すると
14,000行ぐらいソースコード減ったんじゃないですか確か
っていうところもあるので
それぞれ7,000行ずつコードが確か減ったと思うので
それは本当に良かったと思いますね
あと開発環境がモダン化されてやっぱりモチベーションが上がった
エンジニアさんよりも影響がありそう
確かにそうですね
エンジニアは何だかんだ技術スタックとかで
その会社入るか入らないかって一つ大きい基準にやっぱり入るので
そういう意味でも影響はありそうですね
あとそれぐらい体力があったりとか
ちゃんとみんなでやりきれるっていうところの実績が作れるっていうのもかなり大きいですよね
あとこの話聞いただけでやっぱりこの会社さん
エンジニアレベル高いんじゃないかっていう風にやっぱり感じますもんね
これ読むだけで
そういうことをブランディングの観点も含めてのモチベーションが上がったっていうのが良いと思いますね
はいはいはいっていうところでした
そもそもビート化して
実行速度
開発環境を起動するところが18秒から0.2秒になったっていうだけでかなり早いですからね
あとはセットアップ関数からスクリプトセットアップになったってところですね
Vue 2.7でも使えるようになったバックポートになったところですけど
純粋にVue 3の機能じゃないけど
やっぱりVue 3の目玉的な機能ではありますし
プロプスの方がやっぱりつけやすくて
リターンしなくて良くなったっていうのも大きいなっていう風におっしゃってました
未使用の変数の判別のしやすさっていうのが結構見えるようになったらしいですね
セットアップ関数の場合は実際にテンプレートで使われていない変数でも
リターンしているだけで実用
使用扱いになっていたってところですね
はいはいはい
なんですけどこの場合のスクリプトセットアップですね
ではリターンしないのでESLintで未使用変数としてやっぱり判定しやすくなったってところですね
これもかなり大きいと思います
はいはいはい
ところですね
セットアップ関数の中に入っちゃったら結局リターンしているので
使用されているような見方になってしまうっていうのが穴だったんですよね
Vue 2のところですけど
これも確かに大きいですね
15:00
メモリー領域をどんどん確保してしまうので
未使用の変数を持ってしまうと
あとはDefine Propsですね
これはブレイキングジェインスじゃないですけど
公式ドキュメントにも書かれています
TypeScript Only Featuresっていうページ
ハッシュがあるのでそこを見てみてくださいということですけど
型宣言で定義できるようになって
プロップタイプなどを使う必要がなくなった
そういう意味で便利になりましたねということでしたね
確かに最初から型として定義してあれば
別にプロップタイプとかでわちゃわちゃ書かなくてよくなったし
型っていうところを一元管理できるようになったっていうのは結構大きいんじゃないですかね
これもこれで
あとはデフォルト値はwithDefaultでラップする必要があって
そこは面倒だよって言ってました
一応一旦あるし一元管理していなくて
結局今まで通り一個一個手続き的に型を書いてもいいっちゃいいんですけどね
別にプロップタイプ使っても
必要がなくなったとしても別に使う意味では
使いたい人は使えばいいと思いますしね
デファインプロップスを各コンポーネントの冒頭で書くみたいな
ちゃんとコーディング企画だってフォーマットになってるんだったら
それはそれでいいと思いますけど
ただwithDefaultをラップする必要があって面倒であるんだったら
今まで通りの書き方の方がもう慣れてしまってる感もあるので
それでもいい気はしなくはないですけど
モダンじゃないねって感じがしますね
あとはリアクティビティトランスフォームです
これは実験的な機能であるんですけど
そのプロップスのデフォルト値も設定しやすくなるらしいですね
これについてはかずぽんさんのリアクティビティトランスフォーム
っていう別のスライドがあって
それの27ページに書いてあるんで
それも見てみてくださいということでした
まだ実験的ですけど
なんとなくこれはそのまま入りそうな気はしますけどね
あと残りの課題ついでにやったことというところで
ビュックスが肩回りで扱いづらい
そうなんですよ
ビュー2とビュックスはタイプスクリプトの相性がすごく悪い
むしろビュックスが悪いので
なくすとでタイプスクリプトを導入したくないっていう話は
よくある話なので
ここですよね
扱いづらいので段階的にピニアに移行していってる
もうビュー2とはおさらばするそうですね
最終的にはビュックスをなくしたいということですね
今はだから場合によってはビュックス
場合によってはピニアっていうのを導入して
同時並行で使ってるっぽいですね
確かにピニアに移行するのであればそのままタイプスクリプト使えるので
その方がいいんじゃないですかね
タイプスクリプト設定がやっぱりストリクトじゃなかったので
この機会にストリクト化を行ったと
逆に言うと今までストリクトしてなかったんですね
それはそれは
当然エラーが大量に出るので
ツールでattsexpecterrorをつけるようにして
後から段階的に修正できるようにしたと
これは大変でしょうね
github.comの川端亮さんの
suppress-ts-errorsっていうリポジトリのリンクが貼られてますね
これめちゃくちゃ便利だったっていうことはそうです
まあそういうライブラリですね
これが今言ったそのts-expecterrorとか
ts-ignoreみたいなやつですね
そのコメントを書けばそこだけ
一時的に解除されて段階的に入れることができますよ
というやつですね
そういうライブラリが川端亮さんから出されてますというところでした
18:00
まあまあでもこれしないと確かに
もう大量のエラーがオンパレードなので
それを対応するってなると本当にもう大変というか
見た目からどこがエラーなのかもよくわからないみたいな感じになりそうなので
はいこれは真鍮を指しでしたこれも
であとは同時並行して
テイルウィンドカーも実は敷いたらしいですね
いやもうすごいな
同時並行にテイルウィンドカーをぶち込んだんやもう
よくこれやりきりましたね
それも結構重いというか大変すぎるでしょ
へえ
ビュー2だと一部うまく動いていなかったのが
ビュー3でちゃんとなったっていうところで
頑張って導入できたんですね要は
テイルウィンドとビュー3が別にバッティングするわけじゃないので
ここはしかもスタイリングの話なので
ちまちまやればいいんですけど
とはいえちゃんとテイルウィンドにガンってやるというのは
割とドラスティックな変更なので
これでかつ全アプリ
全コンポーネントにやるというのがすげえなと思いましたね
このスライドのフィッシャーの方の体力とバイタリティ本当に
すごすぎて鼻じれそう
はい
で最後まとめて
はい
移行コストvsモチベーション
これ絶対気になってました
モチベーションの話どこに来るんだろうなと思ったら
最後まとめに来ましたね
はいあと学習コストだったりその移行コスト
計算コストとか世の中様々なコストがあります
そりゃそうだよね
でコストを考えるとやっぱやらない方に倒しますよね
やらない勝ちになりますと
で正直どのくらいで終わるのかやっぱ見積もりづらいっていうのが
大きい話ですね
これは本当はビジネスの話ですね
でもやっぱりモダンな環境の方が現場はモチベが出ますし
モチベが高ければ生産性も上がる可能性もあると思いますので
本当はですね企業側としてはお金かかるの
ちょっと渋るかもしれないですけど
やったほうがいいとは僕も思います
現状を変えてここの例を立とうというところですね
はい名言を出てきた感じですけど
とにかく今未来のかを知りたければ
現在の因を見よっていう言葉があるぐらいなので
まさに今未来から帰ってきたみたいなスタンスで
やっぱりやるほうがいいとは僕も思いますけどね
まぁどれぐらいコスト
結局3,4ヶ月かかるんでしたっけ
メンバー何かわかんないし
どれぐらいのビジネスインパクトお金的に
本当だったら作れたお金が失われたかちょっとわからないですけど
まぁまぁその話は多分ここで語られないと思うので
でも頑張ったよってことだそうですね
はいまままとめ最後まとめですね
見積もりづらいがやっていく気持ちが大事
チームで合意決定しておりましょうと
でエラーではなくて振る舞いが変わるところがやっぱりむずい
エラーはだってエラーですから
現状つらい環境ほどやっぱりリターンも大きいよというところですね
はいこれは未来でのかなりリターンが大きいと思うので
初期にしっかりお金をかけていくっていうのは大事だなと思いました
はい以上でこのスライドは終了ということでした
ご静聴ありがとうございましたってことです
いやーこれ本番のプレゼン聞いてみたかったですね
もうすごかっただろうなこれ
やっぱりこれ後編しか聞いてないんですけど
すぐに僕お腹いっぱいな感じがしますので
はいというところで
じゃあまあ30分も過ぎましたので
今日の朝方はここで切りたいと思います
いやー僕はまだそのビュー2からビュー3への移行の
プロジェクトをやったことがないんですけど
結構スタジオさんなのでそれは巨大なプロジェクトなので
21:01
それをやったっていうのはすごかったんだろうなと思いますね
ちょっと怖いもの満たさというか
自分の経験値とかエンジニアとしてのスキルが今錆びつき始めたので
それを手こいでするためにも
もしそういうプロジェクトがあったらなんか飛び込んでみたい感はありますが
まあ結構大変なのかなっていうのもあるので
まあものは選びたいところですね
はいというところで
じゃあ次回は別のスライドですね
アベマさんのリリースから5年ウェブフロントエンドの
経年劣化と向き合うっていうスライドがあるので
これを読んでいこうかなと思います
これ自体はそんなにスライドページ長くないので
1日で終わると思いますね
長くないって言いながら今回のスライドと同じぐらいのページなんですけど
はいじゃあこちらで以上にしたいと思います
月曜日の朝9時から早くからですね
ご参加いただいた皆さん大変にありがとうございました
まだ今日から1週間ですね
かなり今日からまた寒くなってくるんですけど
東京はですけどね
他の地方の方もだいぶ冷え込むと思うので
体調管理気をつけて頑張っていけたらなと思います
では終了したいと思います
お疲れ様でした
