ナタリア・テプルヒナとのスマッシングポッドキャストエピソード26：Vue 3.0の新機能

このポッドキャストのエピソードでは、VueJSについてすべて話します。 3.0リリースの新機能と、移行はどのくらい難しいですか？ ドリュー・マクレランがコアチームメンバーのナタリア・テプルヒナと話をして調べます。

メモを表示

• VueJS
• Vue3移行ガイド
• Twitterのナタリア
• ナタリアの個人的なウェブサイト

毎週の更新

• デジタル製品ページをデザインするさまざまな方法
  スザンヌスカッカによって書かれました
• ReactNativeアプリケーションでのユニットテスト
  フォーチュン池地脚本
• GoogleAnalyticsがUI / UXデザインでWeb開発者を支援する5つの方法
  クララブエンコンセホによって書かれました
• TypeScriptジェネリックを理解する
  ジェイミー・コークヒル脚本の作品
• フェイスモーションを使用してタイポグラフィと対話する方法
  EdoardoCavazzaによって書かれました

トランスクリプト

Drew McLellan：彼女は情熱的なウェブ開発者であり、Google Developerの専門家であり、会議の講演者兼著者です。 現在、彼女はGitLabのスタッフフロントエンジニアですが、VueJSコアチームのメンバーとして最もよく知っているかもしれません。 だから明らかに彼女はほとんど誰よりもVueの周りの自分の道をよく知っています。 しかし、彼女がかつてカンガルーに歌を教えたことを知っていましたか。 私のスマッシングの友達、ナタリア・テプルヒナを歓迎してください。

ドリュー：こんにちはナタリア、お元気ですか？

ナタリア・テプルヒナ：こんにちはドリュー、これは私の家系の名前に対する本当に素晴らしい試みでした。 私はあなたにクレジットを与える必要があります。 英語を話す人が私の名前を発音しようとしたときに聞いた中で最高のことの1つでした。 あなたがロシア語を話さなければ、それは不可能だと思います。 正しい発音はTepluhinaですが、そういうわけで、私は通常、人々に私をナタリアと呼んで、それでやめましょうと言っているのです。

ドリュー：さて、私は努力しました。 しかし、重要な質問は、あなたはスマッシングですか？

ナタリア：もちろんです。

ドリュー：いいね。 それで、今日、Vue3.0のリリースで9月に私たちが持っているいくつかの本当にエキサイティングなニュースについてあなたに話したいと思いました。 バージョン番号の面ではメジャーリリースですが、Vueにとっては本当に大きなリリースであり、かなり長い間作業を続けていますね。

ナタリア：そうです。 私たちは2018年にバージョン3を最初に発表したと思います。それは春に発表されたと思います。実際の作業は春に始まりました。つまり、アイデアは春にあり、実際の作業は2018年の秋に始まりました。 そして、2018年10月に開催されたロンドン会議で正式に発表されたと思います。活発な作業には2年かかりました。 考えてみれば、前のバージョンは2016年にリリースされたので、この4年間の半分はVue3の作業にも費やされていました。

ドリュー：新しいメジャーバージョンが必要だと判断したときの動機付けの要因は何でしたか？ メジャーバージョンで作業するのか、Vue 3で作業するのか、それとも単にバージョンのバンプが必要な変更の蓄積であるというのは、一種の意識的な決定でしたか？

ナタリア：いいえ、いくつかの非常に重要なことから、新しいバージョンを作成することはアイデアだったと思います。 ですから、まず、反応性を変える動機がありました。 前のものはObject.definePropertyに基づいて構築されました。 そして、いくつかの注意点がありました。それらはすべて文書化されていますが、それでもです。 あなたが知っている、あなたが人々がしてはいけないことを文書化したとしても、彼らはとにかくそれをするでしょう。 そして、あなたはそれらをドキュメントに向ける必要があるでしょう。 ちなみに、誰もドキュメントを読んでいません。 何らかの理由でそれはただ起こります。 あなたが人々に指摘するまで、それはドキュメントには存在しません。 でも大丈夫。 とにかく教えます。 したがって、反応性はその1つでした。

ナタリア：パフォーマンスは次でした。 Vue 2のパフォーマンスは依然として最悪であり、最悪のパフォーマンスではありませんが、Vueを高速化する方法についていくつかのアイデアがありました。 また、Vueを使用する視聴者など、私たちの特定の部分に1つの問題点がありました。 それはTypeScriptでした。 Vue 2は内部的にFlowで記述されており、これはまだ強く型付けされていますが、TypeScriptを使用した型付けは、特に状態管理Vuexを使用している場合は非常に悪夢でした。 これもまた大きな部分でした。 そして最後の1つは、コンポーネントではなく、構成可能なロジックパーツの観点から、ロジックを抽象化する機能を見逃していたことです。 関数ヘルパーなどと同様ですが、視聴者のアクティビティも含めることができる必要があります。 ここでの良い例はReactHooksです。これにより、機能の一部を抽象化できますが、これはVueには明らかに欠けていました。 そして今、「あなたはReactから機能を盗んだ」ように聞こえることを私は知っています。 実際にはありません。 アイデアの相互受粉は私たちのエコシステムにおいて大きくて素晴らしい部分であり、開発者がお気に入りを切り替えるのにも役立つと思いますよね？

ナタリア：それで、私たちはこれらの主要な機能に取り組んで、メジャーバージョンとしてVue3を作成しました。

ドリュー：オープンソースエコシステムに存在することの素晴らしい点の1つは、あらゆる種類のさまざまなプロジェクトからの豊富なアイデアと経験があり、それらのアイデアを借りて他のプロジェクトから経験を借りることができることです。プロジェクトは本当に有益で、すべてをより強くしますね。

ナタリア：そうです。 GitLabで反復値を呼び出すのと同じように機能すると思います。 あなたがアイデアを思いついたとき、それは決して完璧ではありません。 これはほとんど、非常に生の、非常にハードコーディングされたもののようなものです。 何かを変えるかもしれませんが、それは間違いなく完璧ではないようです。 そして、それを本当に良いものにするためには、このアイデアを何度か繰り返す必要があります。完璧ではなく、ただ良いものにするためです。 そして、エコシステムのアイデアで起こります。 誰かが良いアイデアを思いついたので、あなたはそれを取り入れて、どんどん良くしていきます。 そして、私は確かに、Vueからいくつかのアイデアを取り入れ、おそらくVueからすでにいくつかのアイデアを取り入れて、それをより良くする何かがあるでしょう、そしてここに悪いことは何もありません。

ナタリア： 「あなたはアイデアを盗んでいる」など、私は強く反対しています。 これは盗むことではなく、単に他家受粉です。

ドリュー：その通りです。 TypeScriptへの移行についておっしゃいましたが、Vue 3自体はTypeScriptを使用して作成されていますが、それは正しいですか？

ナタリア：はい、そうです。 そして、私を信じてください、ドリュー、私はドキュメント、TypeScriptでVueを使用する方法についての小さなドキュメントを書いていました。 そして、私は、おそらくVue 2のようでした。そして、ドキュメントを非常に複雑にしすぎて、すべてを明示的に入力するようなものでした。 すべてが入力されているように見えます。 私はタイプを見ることができるので、私のts-linkは幸せで、これまでのところとても良いです。 そして、TypeScriptを使用していた開発者の1人が、「これを行う必要はありません」と述べました。 どのように、どのように？ 「データに対して明示的な型を行う必要はありません。 あなたはそれに初期値を与えるだけで、ts-linkはその数を知っています。 すでに入力されています。」 どうして？ 「ドキュメントから明示的なタイプの90％を削除しました。 実際に入力する必要があるのは、コンポーネントのプロキシと、計算されたプロパティの2つだけです。 それでもリターンタイプが必要です。 しかし、残りは自動的に入力されるようなもので、definecomponentと呼ばれるメソッドを使用してコンポーネントを作成するだけです。 以上です。 タイプされました。」

ナタリア：それは、それがうまくいくようなものでした。 そして私にとって、そして私は過去の経験でAngularをたくさん使っていましたが、TypeScript用のストックホルム症候群があります。 すべてを明示的に入力する必要があります。 つまり、複雑な型がある場合は、もちろんインターフェイスを作成する必要がありますが、これがTypeScriptの動作方法です。 それでも、現在Vue3でTypeScriptを使用する方がはるかに簡単です。

ドリュー：それは素晴らしいことです。Vueコアプロジェクトと、Vueを使用してアプリケーションを構築している開発者の両方にとってメリットがあります。これは、2.0では使用できなかったVueでTypeScriptをアプリケーションでうまく使用できるためです。 2.0のとても簡単に。 Vueコミュニティに精通している人は、Vueの作成者であるEvanYouがまだ非常に積極的にプロジェクトを主導していることに気付くでしょう。 コアチームはどのように機能しますか？ 開発プロセスに関しては、どのように構成されていますか？ エヴァンだけじゃないの？

ナタリア：それはとても素晴らしい質問です。何年もの間、人々はVueについて次のように話していたので、私はこれを引用し、厳しいように聞こえますが、申し訳ありませんが、「中国のフレームワークのように、1人の中国人のフレームワークです」 。 つまり、Vue 1.Xでも、すでにチームがあり、Vue 2の背後には大きなチームがあり、Vue 3の背後にはさらに大きなチームがありました。Vueについて話すとき、私たち全員が異なる責任を負っています。

ナタリア：コアに取り組んでいる人がいますが、これはエヴァン自身だけではありません。彼は間違いなくVueコアでほとんどの作業を行っており、プロジェクトも主導しています。 しかし、Vue Coreで働く人々がいて、彼らの貢献は絶対にかけがえのないものです。 また、Vueチームに加わって、Coreで働く新しい人々が数人います。 また、エコシステムに取り組んでいる小さなチームもあります。Eduardoのように、Pure Routerに取り組んでいる人々もいれば、Vue CLI、Vuex、ドキュメントにも取り組んでいる人々がいます。

ナタリア：ドキュメンテーションは重要であると私たちは信じているので、ドキュメンテーションに取り組むチーム全体がいます。 そして現在、私たちのウェブサイトには、コアチームに属する21人、20人、または21人の人が常に数えられないと思いますが、これは静的なリストではありません。 私たちは明らかに採用していないので、私たちはオープンソースチームであり、これは有給の仕事ではありません。 しかし、誰かがVueエコシステムのいずれかの部分に多大な貢献をしている場合、人々がすでにコアチームメンバーの仕事をしているとき、それはただ、リポジトリと正式なタイトルにアクセスするだけで彼らに認識を与えると信じています。

Drew：オープンソースプロジェクトに貢献することで、個人に実際に何らかの見返りを与えることができるので、それは素晴らしいことです。 彼らはある程度の認識を得て、それはあなたのプロとしてのキャリアとあなたが持っているものに影響を与える可能性があります。

Drew： Vueに慣れていないかもしれないが、ReactやAngularなどの他のリアクティブフレームワークに精通しているリスナー向け。 Vue 3での大きな、ある種の見出しの変更は何ですか？具体的には、彼らが解決しようとしている問題は何ですか？ 先ほど作曲についておっしゃいましたが、それは大きな変化のひとつですか？

ナタリア：はい、これは最大の変更の1つであり、実際には、まず第一に、ここで明確に述べさせていただくことの1つです。 構成APIは純粋に付加的です。 コンポーネントを書き直す必要があるわけではありません。TypeScriptをコンポーネントに追加できます。 または、すべての構文を使用することをお勧めします。これをオプションAPIと呼びますが、これらの用語では何も変わりません。 新しいAPIについて話しているとき、これは重大な変更ではないようなものです。 これを強調したいのですが、Composition APIを最初に発表したときはひどい瞬間だったので、言うことは非常に重要です。

ナタリア：変更点をうまく説明していなかったと思います。標準ビルドはCompositionAPIになるように見せました。 それは完全に私たちの悪いことであり、オプションは次のようなものでした。おそらく、Vue 3ではなく、将来のビルドで明らかに非推奨になるでしょう。 そして、あなたが間違って言ったことを人々が読む可能性があるなら、彼らはそれを間違って読むでしょう。

ナタリア：この声明の直後、変更を提案したのはRFCで、Redditが爆発しました。 Redditは、「ああ、なんてことだ。 私はすべてを書く必要があります。 何てことだ。 Vueは新しいAngularです。 彼らはすべてを壊そうとしているのです。」 そして、dev.toにVue's DarkestDayという記事を作成した人がいました。 正直なところ、最も暗い日でした。 私たちはそう感じましたが、私は自分のツイッターでこれと戦おうとしているようなものでした。 それで彼は「これをすぐに書き直します。 マスターにプッシュするようにしましょう」。 人々はこれに腹を立てていました。 彼らは特定のポイントについて議論していたので、ページを更新するだけで、それらのポイントはもう存在しません。 あなたは、私がばかなのか、それともただ…一体何なのか、と感じます。 つまり、それはまさにそこにありました。 私はこれを覚えています。 そして、私たちのコミュニケーション戦略はもっと良くなる可能性があると私は信じています、そしてこれは私たちではありません。

ナタリア：今、私が作曲について話すたびに、これは純粋に相加的です、人々。 これは素晴らしい機能です。 あなたはそれを使うことができます、あなたはそれを使うことができません、あなたは義務ではありません。 ただ…存在します。

ドリュー： Composition APIがその問題から抜け出すのに役立つ新しいものである場合に、誰かが自分自身に陥る可能性のある問題の種類は何ですか？ それはどのような問題を解決していますか？

ナタリア：内部にいくつかの機能があるコンポーネントを想像してみてください。 検索と並べ替えだとしましょう。 特定のリストを検索し、それを並べ替えようとしたとします。 これはすでに2つの異なる機能であり、Vueコンポーネントの特徴は、ロジックではなく、オプションに基づいて分割されていることです。 検索と結果の配列を検索するためにクエリを作成する必要があるため、検索におそらくクエリがあると想像してください。 そして、これらは2つの反応特性です。 コンポーネントに関しては、データと呼ばれるオプションにそれらを配置します。 そして明らかに、ソートを実行するための何らかの方法が必要です。 たぶんボタンクリック、たぶん何か他のもの、検索を実行する何か。 メソッドを作成します。 また、並べ替えには、別のリアクティブプロパティである並べ替えオプションに基づいて何かを構築する必要があります。 次に、計算を実行して結果を並べ替えます。

ナタリア： Vueでは、このために、別のオプションである計算されたプロパティもあります。 最後に、コンポーネントは本当に断片化されました。 そして、私が開発者であり、部分の検索のみに取り組むタスクがあると想像してください。 これらの2つの機能は、ある意味でクロスしているため、現在、コンポーネントを分割することはできません。 いくつかの結果を検索して並べ替えます。 そして、データからメソッドへ、メソッドから計算へとジャンプする必要があり、最後にコンテキストを切り替えるのは本当に難しいです。 特にコンポーネントが非常に大きくなる場合。

ナタリア： Vue 2.0にはどのようなオプションがありましたか？ 最初のオプションはミックスインと呼ばれ、ミックスインはコンポーネントが持つことができるのと同じプロパティを含むことができる単なるオブジェクトであり、コンポーネントとそれらをミックスしています。 良さそうですね。すべての検索をそこに移動できますが、何が問題なのですか。 いくつかあります。 まず、これは完全に柔軟ではありません。 特定のエンドポイントを検索し、これをミックスインに移動した場合、これが検索できる唯一のエンドポイントになります。 Mixinはパラメータを受け入れません。 ミックスインを作成しました。完全に静的です。 2番目の問題は、ミックスインが混在していることです。これは、特定のプロパティでは、マージのように発生することを意味します。 たとえば、フックを作成した場合、それはマージされます。 ミックスインコンポーネントのライフサイクルフックのすべてのロジックがマージされます。 ただし、データプロパティ、ミックスインにコールドクエリがあり、万が一コンポーネントに同じものがある場合は、コンポーネントが優先されます。 上書きされます。 警告はありません。 絶対。 それはただ起こるでしょう、そしてあなたはこれが起こったことを知らないでしょう。

ドリュー：すべてのスコープが完全に混合されていますか？

ナタリア：うん、完全に。 あなたが見る可能性はありません、そしてまた、ミックスインは非常に不明確な情報源です。 名前を付けてミックスインをインポートし、コンポーネントプロパティのミックスインを表示するために配置するだけです。 それは非常に暗黙的であり、私自身の経験の観点からこれについて話している。 GitLabには、コンポーネントに2つのミックスインが含まれ、これら2つのミックスインのすべてに別のミックスインが含まれるロジックがあります。 そして、ここに行きます、ここにあなたがチェックする必要があるプロパティがあります、そしてそれはコンポーネントにありません。 もっと深く、最初のレベルのミックスインに行きましょう。 これはそれを含んでおらず、これもそれを含んでいません。 どこですか？ あなたはうさぎの穴を深く掘り下げて、この特性を見つけるためだけに深く潜っています。テストも悪夢になります。

ナタリア：ミックスインは、ロジックを抽出するための非常に馬鹿げた方法です。 それは明白です、それは明白です、それは非常に簡単に手に入れることができます。 これを高度なレベルで処理したい場合は、非常に多くの問題が発生します。 Vue 2.0でロジックを抽象化する次の方法は、レンダリングのないコンポーネントでした。 Vueでは、コンポーネントにスロットを含めることができます。 基本的に、親コンポーネントから何でも置くことができる部分。 小さな窓、実際にはスロット。 そして、スコープスロットのアイデアがあります。 独自のスコープを親に公開できる子コンポーネントを想像してください。スロットコンテンツはこれにアクセスできます。 スロットのあるコンポーネントがあり、コンポーネントが検索に関するすべてのロジックを実行するとします。たとえば、過去のパラメーターを持つエンドポイントを持つ検索を考えてみましょう。 検索などの子コンポーネントは、スコープのこの部分を親に公開します。 これらは検索結果です。 楽しみ。 いいですね。 ミックスインよりも間違いなく良い音がします。 パラメータをテストできます。 ここではロジックが明示されており、何かを返しています。 問題？ いくつかあります。

ナタリア：まず、コンポーネントインスタンスを作成しました。 これは世界で最も安い操作ではありません。 第二に、それは実行時間です。 コンポーネントは実行時にのみ機能します。つまり、このコンポーネントから公開されたプロパティは、スロットのスコープとして公開したスロットでのみ使用できるため、検索結果はテンプレートのごく一部でのみ利用できます。 コンポーネントの個別の部分で遊んでみたい場合は、そこにアクセスすることはできません。 ランタイムです。 他の場所でリアクティブ状態が必要な場合は、このロジックを実行する必要はありませんでした。 もちろん、純粋関数のようなヘルパーを作成して結果を返すことはできますが、リアクティブプロパティを操作する必要がある場合はどうなりますか？ このようにして、CompositionAPIが作成されました。 Composition APIを使用すると、スタンドアロンのリアクティブ状態にすることができます。 反応状態は、もはやコンポーネントの一部ではありません。 任意のオブジェクトまたはプリミティブをリアクティブにすることができます。 そして、あなたはそれを親に公開することができます、それは非常に明白です。

ナタリア：親に返したいすべてのプロパティが公開されます。 それは明白です、あなたはこれをクリックすることができます、あなたはそれがどこにあるか、それが何であるかなどを見ることができます。 そして最良の部分は、Composition APIの一部を、データメソッドやコンピューターのプロパティなどを備えた古い優れたコンポーネントに含めると、正常に機能することです。 完璧に機能します。コンポーネントにいくつかのリアクティブプロパティとメソッドを追加するだけで、古いオプションAPIでも使用できます。

Drew：これは、非常に複雑なコンポーネントや、コンポーネントのやや複雑な組み合わせに関しても、開発者がコードベースをクリーンアップするのに本当に役立つように思えます。 そして、ミックスインなどのテスト容易性についておっしゃいましたが、Composition APIはより良いテスト可能性を可能にしますか？

ナタリア：はい、確かにコンポジションAPIです。これからライフサイクルフックを除外すると、コンポーザブルで別のライフサイクルフックを実行することもできます。 それは実際には純粋関数です。 あなたはSパラメータを持っています、あなたは何かをしています、そしてライフサイクルフックの外でまだ副作用があります。 そして、ご存知のように、純粋関数をテストするのがおそらく最も簡単なことです。 これは単なるブラックボックスであり、Sパラメータがあり、返すものがあります。

Drew：これは、Vueを使用してより複雑なアプリを作成している多くの人が喜ぶと確信している問題に対する非常に包括的な解決策に聞こえます。 そして、それは確かに、ミックスインで忍び寄ることができると私が知っている種類のバグを排除するための本当に素晴らしい方法のように聞こえます。

Drew：フレームワークの上に構築することを選択するときの大きな考慮事項は、長期にわたるAPIの安定性だと常に思います。 安定性は正しい言葉ではないかもしれませんが、私たちの多くはフレームワークの上に構築することに悩まされ、その後大幅な手直しを経て、移行するために巨額の投資を必要とするか、単にバインドされてしまうアプリを残していると思いますその後サポートされなくなったフレームワークの古いバージョンに。 そこにいるのは恐ろしい状況です。大きなプロジェクトをVue2からVue3に移動すると、どれだけの睡眠が失われるのでしょうか。

ナタリア：まず、APIサーフェスは以前と90％同じです。 非推奨のイベントハブに置き換えることができる非推奨のものや非推奨のフィルターはそれほど多くありませんでした。 EventEmitterを使用する場合は、ビューベースのライブラリを外部ライブラリに置き換える必要があります。 これらは大きな変更ですが、移行について言えば…はっきりさせておきますが、私はVue JSコアチームのメンバーであるため、今は本当に引き裂かれています。 一方、私はVueを使用する大きなプロジェクトのスタッフエンジニアです。 今すぐ移行を開始しようとしている場合は、移行を開始することはお勧めしません。 まず、エコシステムはリリースされていません。つまり、Pure Router、PUX、Vue CLIなどのコアライブラリについて言えば、これらは良好な状態ですが、リリースではなく、リリース候補です。 また、コアライブラリではない、UIコンポーネントライブラリ、フォーム検証ライブラリなど、他のエコシステムについて話す場合、ほとんどの場合、Vue 3の準備ができていません。また、大きなプロジェクトがある場合は、必要な依存関係が非常に多くあります。お手入れ。 したがって、これは複雑なことです。

ナタリア：オプションとは何ですか？ あなたは大きなプロジェクトを持っていて、このすべてのコンポジションAPIの良さを使いたいと思っています。 これを達成する方法は？ まず、Vue 2.0、Vue2.7のLTSビルドをリリースする予定です。 これには多くの非推奨の警告が含まれるため、非推奨になるもの、Vue 3で破損しないようにリファクタリングする方法を確認できます。したがって、技術的にはVue 2を使用しますが、Vue3を準備します。とにかく、すべての警告があるからです。

ナタリア：次に、それを実行するだけの移行ツールを使用します。これはcodemodとして機能し、Vue2に関連するものをVue3の代替手段に置き換えます。 もちろん、完璧なコードモッドはありません。 まず、可能な限り交換を行うことを目指していますが、非推奨が簡単に処理できない場合は警告も表示します。 Codemodは物事を認識して警告をスローすることはできますが、それ自体を置き換えることはできません。 これは大きな計画のようなもので、Vue 2.7がリリースされた時点で、正確に覚えていれば、今のところ到着予定時刻は12月だと思います。ロードマップを確認する必要がありますが、12月だと思います。

ナタリア：エコシステムも多かれ少なかれ準備ができています。 Vue 2.0を使用する大規模なプロジェクトがある場合は、Coreが安定するまでもう少し待ってください。完璧なライブラリを作成しても、人々がこれを使い始めてバグを報告し始めるため、安定するまでに時間がかかるからです。 ペットプロジェクトに使用してバグを報告する場合は、大歓迎です。 そしてこの後、Vue3に移行するための良いスムーズな方法があります。

ドリュー：それで、あなたが言及した移行ツールは非常に興味深いように聞こえます。 これは基本的に、コードを調べて…

ナタリア：はい、はい、はい、それはコードまたはツールです。 現在、ごく限られた方法でご利用いただけます。 VueCLIのプラグインとして利用できます。 Vue CLIベースのプロジェクトがある場合は、Vueアップグレードを実行して、ツールがどのように機能するかを確認できます。 今のところ私たちが望んでいる形ではありません。 残念ながら、私はVueCLIで構築されたプロジェクトに取り組んでいません。 何が起こっているのかを待って確認する必要がありますが、たとえばGitHubの場合、非推奨になっていることがわかっているため、移行ツールがなくても、すでにいくつかの手順を実行しています。 実際には、Vue3のドキュメントに記載されています。

ナタリア：移行ガイドがあります。 すべての重大な変更と非推奨になっているものを確認でき、Vue2.0コードベースでもそれらの一部にすでに取り組むことができます。 たとえば、Vue 2.6では、スロットの構文を変更しました。 スコープスロットの構文は非推奨になりましたが、拒否されませんでした。まだ存在しています。 警告が表示されますが、実行できます。 そしてもちろん、7年前のコードベースでは、非推奨の構文がすべて機能するのであれば、それを置き換えることを誰も気にしません。 本番環境では警告はありません。 スロットは機能します。 「ああ、コンソールに警告が表示されます。 多分それらの20、結構です。 赤ではなく黄色です。 私は気にしません」。

ナタリア：あなたはそれが誰にでも起こることを知っています。 これに取り組むために巨大な叙事詩を作成しました。 古い構文の現在のセットをすべて検索します。 私たちはEventEmittersを置き換える努力をしていますが、これも7年前のプロジェクトであり、私たちを判断しないでください。 EventEmittersがあります。 GitLabはEventHubsに取り組んでいました。 Vueベースの楽しみを外部ライブラリに置き換えました。 同じことをお勧めします。 移行ガイドに目を通し、すでに置き換えられるものと、これを準備して作業を開始するためにすでに行うことができる変更を確認します。

Drew：移行ツールの現在の状態を使用すると、コードベースで水域をテストするだけの良い方法になります。 それを実行して、それがすでにフラグを立てているものを見て、それが大丈夫に見えるかどうか、またはいくつかの大きなものがあるかどうか、またはそれがまだ未成熟であるかどうかを確認するだけですか？ 実際に問題が解決する可能性がある12月まで待つ方がよいでしょうか。

ナタリア：もし私が大きなプロジェクトを持っていたら、そうすることはお勧めしません。 小さな悪いプロジェクトや個人的なプロジェクトがあるが、それほど大きくない場合は、2つの中規模プロジェクトで実行しているので、実行して問題を確認することをお勧めします。 私は1つか2つの問題だと思います。 未熟とは言えません。 すでに良い状態です。 しかし、再び大きなプロジェクトの場合、それはレガシーであり、いくつかのエキゾチックなものです。 人々、本番環境ではこれを行わないでください。

ナタリア：また、プロジェクトの足場を試してみたい場合は、現在VueCLIで2つのモードがサポートされています。 Vue 2プロジェクトを作成でき、Vue3プロジェクトを作成できます。 そして、少なくとも試してみてください。 これは私たちにとっても良い方法です。なぜなら、プレイすると、バグを発見したり、バグを報告したり、修正しようとしたりするからです。

ドリュー：ドキュメントと開発ロードマップに、移行ビルドについての言及があります。 それは私たちが話していることとは違うものですか、それとも私たちが話していることですか？

ナタリア：いや、いや、同じだ。 これは同じで準備ができているはずですが、今のところ、移行を計画している場合、メインパスはドキュメントを読んで、そこに記載されている内容に従うだけです。移行ツールがない場合は必ず努力するため、ドキュメントチームが先に進みました。ここで、変更とは何か、変更が行われた理由、実際には何が置き換えられるかについての詳細なガイドを作成しました。

Drew：はい、ドキュメントにはVue 3ドキュメントの一部としての非常に包括的な移行ガイドがあり、移行が必要な非常に多くの変更について言及しています。 それらのいくつかはすべてのプロジェクトに影響を与えるわけではないと思います。 それらの多くは、本質的に多くの人々にとってエッジケースでした。 それは公平ですか？

ナタリア：はい、たとえばフィルターなど、それらのかなりの部分は確かにエッジケースです。これは、GitLabでさえ、3回目となる7年前のコードベースと大きなコードベースを備えているためです。 フィルタが1つか2つあり、それらはもう使用されていません。 「ああ、未使用のコード」のように、それを気にする人がただ存在するので、それらを検索して完全に削除したのは良いことでした。

ナタリア：完全に破壊的な変更はモデルの変更だと思います。 確かに、私が知っているすべてのプロジェクトには少なくとも1つのVueモデルが含まれているので、これを見てください。 現在、クラスとスタイル、チューブラーとエーテルが含まれているため、これを確認する必要があり、属性も変更される可能性があります。 また、Vueを使用したことがある場合、以前は含まれていませんでした。 現在、クラスとスタイルを子コンポーネントに渡す方法は少し異なり、注目に値します。

ドリュー：それは知っておくと良いことです。 Vueでリリースされる3.0リリース、つまり、エコシステムとその周辺のすべて、Vuex、およびそのレベルに進む必要のあるエコシステムの他のすべての部分について言及されました。 そのため、現在、ウェブサイトの大きな「はじめに」ボタンはすべてVue 2に移動していますか？ Vue 3がリリースされたような気がしますが、完全な自信はありません。 しかし、それがまだそのようなものであるのは、その生態系の問題のためですか？

ナタリア：いいえ、バグを見つけたと思います。すぐに確認させてください。 いいえ、始めましょう。Vue3を指しています。問題ありません。 つまり、vuejs.orgにアクセスすると、バージョン2を指しているということです。 これは、進行中のVue 2のようなサブドメインに置き換えることを計画していたため意図的ですが、これまでのところ、vuejs.orgをそのままにして、Vue 3を作成することにしました。そのため、vuejsにバナーがあります。 org。 いずれかのドキュメントにアクセスする場合-

ドリュー：上部に非常に小さなバナーがあります。

ナタリア：はい、小さいようです。

ドリュー：うん。

ナタリア：もっと大きくする必要があると思います。 より大きく、より良い色のコントラスト。 私のアクセシビリティの気持ちは、「ああ、そこにはコントラストがない」というようなものです。

ドリュー：それは良いニュースです。 誰かが始めている場合、おそらく大きなプロジェクトではありませんが、誰かが個人的なプロジェクトを始めている場合、またはVueを学びたい場合は、確かに、Vue 3が開始する場所ですか？

ナタリア：そうだと思います。 ちなみに、学習曲線はそれほど変わりません。 古い構文オプションを使用することはドキュメントチームの意図であったため、古いと言うべきではありません。実際には現在の構文です。 デフォルトの構文としておなじみの構文。 Vue 3のドキュメントを読むと、Composition APIは高度なトピックでのみ表示され、Vue3での学習パスはVue2での学習パスと似ているためです。新しいものから始めるのは大したことではありません。 Vueを学んで実験してみれば、バージョンです。キャリアについて話すと、より良い投資になると思います。 すべてのプロジェクトを追い抜くため、新しいバージョンの学習を開始します。 最終的には、おそらく半年、1年、大規模なプロジェクトであっても、移行が行われるでしょう。

ドリュー：私は個人的なキャリアの中で、大規模な移行の過程にあるのと同じようにプラットフォームに来るという本当の才能を持っているようです。 つまり、Macromedia Directorがずっと前に戻って、Shockwave、Flash、その他すべての種類のものを覚えていますか。 彼らがドット構文に移行しているときに私はそれに到達し、私は両方を学ばなければなりませんでした。 そして、私は先月、Vueで初めてプロジェクトに取り組んでいます。これは、Vue 2プロジェクトであり、Vue 3で行われるすべてのことを楽しみにして、学習していきます。移行しながら何かを学ぶのは確かに興味深い時期ですが、Vueではそれほど難しくないように思えます。エコシステムがコアに追いついたら、私たちは良い場所にいるはずです。

ナタリア：ああ、ドリュー、私はあなたが大きなプロジェクトの移民について言ったことについて指摘したいだけです。 2018年のように、私はGitLabに参加しています。 私はコアチームのメンバーではありませんでした。現時点では、私は単なる貢献者です。

ナタリア：すぐに、エヴァンは「ああ、Vue3を作るつもりだ」と言っています。 みんな「うん、かっこいい」が好きです。 2019年の春、あなたはコアティームです。 つまり、GitLab全体が「ああ、これはかわいい。 私たち全員が移行を行っていますが、誰がこれに責任を負っているのかご存知ですか？」 そして、Vue 3のドキュメントを書くと、誰もが読んで、あなたの会社は「ああ、Vue 3について何かを学びたいのですが、あなたのドキュメントを理解できません」のようになります。 つまり、あなたは「ああ、これはとても辛い」というようなものです。なぜなら、あなたはそこで開発者であり、テクニカルライターであるからです。

ナタリア：あなたはその真っ只中にいますが、フレームワークで作成された大きな製品は、バグを見つけてライブラリに戻すための素晴らしい、絶対に素晴らしい戦場であるため、フレームワークにとっても非常に有益であると言わざるを得ません。生態系。 テストと言えば、GitLabはオープンソースのVue Test Utilsであり、Vueのテストツールです。 チームは、テストに基づいたテストコードを使用していました。これは、非常に理にかなっています。 いくつかのエッジケースなどを見つけることができるからです。 それでも、GitLabをVue 3に移行することを考えると、これに対する個人的な責任のように感じます。 私は移行の最中であるだけでなく、私たちが見つけるすべてのバグに対して個人的に責任があります。

Drew：前世代のJavaScriptフレームワークを振り返ると、当時最も成功したものの1つはjQueryだったと思います。また、非常によく設計されたAPIを備えていたため、注目を集めたと思います。 CSSセレクターを使用してJavaScriptのDOMを照会するというこの概念は、jQueryが普及させたものでした。 And I think that really resonated with hardworking developers who didn't need to learn a new way to work with JavaScript. I see Vue almost being I that same sort of camp. I mentioned I was previously working with React and moved to Vue in the last few weeks, and I found that almost everything to be more intuitive in the most genuine sense, as in I can look at something unfamiliar and pretty much understand what it's doing. And if I need to do something I've not done before I can sort of guess at how it would be implemented and usually I'm right or close to it.

Drew: Is the API of Vue something that the Core Team think about very closely or has it just turned out well almost as a happy accident because of the personalities involved?

Natalia: I think, at the times of Vue 2 we had a concept. It's changed slightly but we had a concept that was called Documentation Driven Design. And it's a really great concept because if something is really hard to explain, really hard to get and really hard to write down, maybe the API is wrong there. Maybe something is not developed as it should be because non-intuitive solutions, something that is like very cryptic, and you need to put a lot of work to explain, usually is not right. The API was shaped the way that is the easiest to explain and that's why it's intuitive. If it's easy to explain, people probably will get it on themselves. That's why the older directives like v-if and v-for look very familiar for any JavaScript developer. You don't need to explain what v-if is doing because it's clear, right.

ドリュー：そうですね。

Natalia: It's kind of insulting and same with v-else. V-if, v-else-if, v-else and that's it. And we intuitively built v-for with syntax that looks like for loop in JavaScript and same for the biggest part of the API. I think the main intention since Vue 1.x and I think Evan also stated this in his docs was to create something that you have pleasure to work with as a tool. It's all about developer experience as well and I think this is what attracted me in Vue back in time as well. I started with Vue when it was already in beta for version 2. I didn't work that much with Vue .1. I think were not that many people familiar with Vue from the first version but I was like, “It's so nice to use”. I'm just building the same stuff and it's just been a pleasure. I don't need to think about the tool, I'm thinking about what I'm going to build. And tool is not preventing me from doing this.

Natalia: And again, I need to state this next one will be totally personal opinion, not as a Vue Core Team member. I've been working with Angular from version two to version six on a commercial project and it's a great framework. There are many different terms, it has lots of abstractions, the dependency injection is amazing, TypeScript support is absolutely incredible but I constantly had the feel I am building a wall with huge heavy bricks. And I need to just make an effort to move every single brick. I mean, the wall is amazing. Bricks are still heavy and it's just hard being a developer. And after this, working with Vue is like, “Oh, it's just like a walk in the park”.

Drew: There can be a danger with software that when it's so well designed, it makes everything feel really easy, that it sort of gets branded as a toy, as not being as powerful as the things that are really complex. Do you think that's a risk with Vue, do you think it might be regarded as less serious as some of the other reactive frameworks simply because it's better designed?

Natalia: Oh, it was. It was for this reason and for a few more reasons as well. And honestly, for a good amount of time, I think I had this question, every single conference I'd been speaking at, “Would you recommend Vue for big sized project, for enterprise project, for like serious project.” And every single time I was like, “Yes, you can use it for small project, it's easy to scaffold something, you can use it for the big size project and honestly if we speak about enterprise size project, framework is the least of the issues you need to solve.

Natalia: You can take any framework on the market, be it old one, be it Amber, be it whatever else, be it Angular One and create a good and stable architecture. You can take any of the newest framework, like latest release Vue 3, Svelte, latest React and build absolutely, incredibly awful stuff. It depends on how build it and how your team is working on this, whatever you have there, how you planned all the architectural decisions because I think, none of the framework, maybe Angular a bit, is dictating an architecture. Angular kind of does this thing rest of them are like, “You're free. Build it.” And yes, also I think the issue with Vue, not an issue, but issue in minds of people and especially in minds of company management was it's not backed by a big company.

Natalia: You have an Angular and there is Google standing behind Angular. There is React and there is Facebook supporting React. There is Vue and who is the small Chinese guy, again this is like a stigma, there is a framework of one guy, what if Evan You is hit by a bus? There was an article, “What if Evan You is hit by a bus”, I swear on dev.to. I'm like, “What are they so scared” and big companies are probably like, “What if they drop support, what if they decide, maybe even he decides, if we speak about Evan, what if he decides he does not want to work on this.” And as we can see over years it's good and stable and it's developing and it's not an issue and honestly, I think when framework is completely open sourced and built with a team of people that are not engaged, that are not subjective, that are not under one big company it's actually better for the framework.

Natalia: Last year we introduced the RFC process. It's actually just a request for comments. We have an idea, we drop it, people come there and people argue there and if we create an RFC for anything, this means that it's not decided, it's not set in stone. We just have an idea and we want to hear what community thinks. I believe it's great because Vue is shaped by developers community. This is not just loud words. No, this is not a production slogan, by the community for the community, I remember we used this but it's true. It's actually shaped by community. It's not shaped for the needs of a certain company. Even for big companies, even for companies that are sponsoring Vue. They're not shaping the framework and I believe this is great.

Drew: It's quite telling when you mentioned the list of active Core Team members is 20ish people and they're all listed on the site and next to everyone it says what thy work on in the project and also where they work professionally. And just looking down the list of where people work professionally, I mean you're at GitLab and there are other people who are just independent consultants and it's not like 18 of the 20 people work at Big Corp. Everybody is just contributing from all over the place which, as you say, is a real point of strength.

Natalia: Yeah.

Drew: That there is no one big body controlling it that could, for their own business purposes, just say, “We're changing direction, we're not going to do this anymore” and pull away all that support and leave the project in a mess. It is just lots of individuals contributing and doing their best to make something good, which I think is a really strong foundation for something as important as a framework that people are building on top of.

Drew: You know I've spent the first half of this year learning React and then changing jobs and now learning Vue. Personally it feels to me like a breath of fresh air. And I really want to commend the work that you and your colleagues are doing on that. For those who are wanting to find out more about Vue, the 3.0 release or just generally about Vue, you can go to vuejs.org currently the version three specific version as we mentioned is linked to the little banner at the top. Maybe by the time you're listening to this, the site will have changed and will just be Vue, but that's also where you find the docs and in the docs is that really good migration guide that we mentioned. I've been learning all about Vue 3.0, what have you been learning about lately, Natalia?

Natalia: I've been learning about Apollo Client version three. It's funny, because if you look at versions and I've been watching both of them, they are going completely the same way. Apollo Client was 2.6 and Vue was 2.6. And Apollo promised a release for a year and they were delaying and delaying it. It was for a long time in beta then release candidate. Same was for Vue, we announced a release and then we were delaying it again and again and moved to beta a bit late and then moved to release candidate. And they released not the same time but not with a big time difference. Apollo I think was released in Summer, beginning of Summer.

Natalia: And we use Apollo as well. I use it professionally and now I kind of try to build something with Vue 3 and Apollo 3, which is not an easy task because Apollo did a good number of changes. Again, we're adjusting them at work but, for example, removing local resolvers, is like, “What do I do now? What do I do with my local queries?” If you're curious about Apollo Client version three definitely give it a try. It's interesting to see how it's evolving.

Drew: I'm definitely going to give that a try. I've used Apollo on a couple of projects and it's really great to see that pushing ahead as well. If you as a listener would like to hear more from Natalia, you can follow her on Twitter where she is N_Tepluhina and you can find collections of her articles and videos of her public speaking events, much of which is about Vue on her website, nataliatepluhina.com

Drew: Thanks for joining us today, Natalia. Do you have any parting words for us?

Natalia: Not really, but thank you for having me, it was a lot of fun to speak there.