Quoi de neuf dans Vue 3.0?

Dans cet épisode de podcast, nous parlons de VueJS. Qu'y a-t-il de nouveau dans la version 3.0 et à quel point la migration sera-t-elle difficile? Drew McLellan s'entretient avec Natalia Tepluhina, membre de l'équipe principale pour le savoir.

Afficher les notes

Mise à jour hebdomadaire

Transcription

Drew McLellan: Elle est une développeur web passionnée, une Expert en développement Google, conférencier et auteur. Actuellement, elle est ingénieur frontale chez GitLab, mais vous la connaissez peut-être mieux en tant que membre de l'équipe de base Vue JS. Il est donc clair qu'elle connaît mieux Vue que presque n'importe qui. Mais saviez-vous qu'elle a déjà appris à chanter à un kangourou. Mes amis Smashing, veuillez souhaiter la bienvenue à Natalia Tepluhina.

Drew: Salut Natalia, comment vas-tu?

Natalia Tepluhina: Salut Drew, c'était une très belle tentative sur mon nom de famille. J'ai besoin de vous donner des crédits. C'était l'une des meilleures choses que j'aie jamais entendues d'un anglophone quand ils essayaient de prononcer mon nom de famille. Je suppose que ce n’est pas possible si vous ne parlez pas russe. La prononciation correcte est Tepluhina, mais c’est la raison pour laquelle je demande généralement aux gens de m’appeler Natalia et arrêtons-nous là.

Drew: Ok, eh bien, j’ai fait un effort. Mais la question importante est, est-ce que vous Smashing?

Natalia: Bien sûr que je le suis.

Drew: C'est bien. Je voulais donc vous parler aujourd'hui de certaines nouvelles vraiment excitantes que nous avons en septembre avec la sortie de Vue 3.0. C’est une version majeure en termes de numéro de version, mais c’est vraiment une grosse version pour Vue, et elle est en préparation depuis un certain temps, n’a pas le temps?

Natalia: Ça l’est. Je pense que nous avons annoncé la version trois pour la première fois en 2018. Je pense qu'elle a été annoncée au printemps, et le vrai travail a commencé, je veux dire, les idées étaient au printemps, le vrai travail a commencé en 2018 à l'automne. Et je pense que cela a été officiellement annoncé à la Conférence de Londres, qui s'est déroulée en octobre 2018. Le travail actif a duré deux ans. Et c'est beaucoup si vous pensez que la version précédente a été publiée en 2016. Donc, la moitié de ces quatre années ont également été consacrées au travail de Vue 3.

Drew: Quel était le type de facteur de motivation pour décider qu'un nouveau version majeure a été demandée? Était-ce une sorte de décision consciente que, d'accord, nous allons travailler sur une version majeure, nous allons travailler sur Vue 3, ou était-ce juste une sorte d'accumulation de changements qui nécessitaient simplement un changement de version?

Natalia: Non, je pense que c'était une idée de créer une nouvelle version en raison de quelques éléments très importants. Donc tout d'abord, il y avait une motivation pour changer la réactivité. Le précédent était basé sur Object.defineProperty. Et il y avait quelques mises en garde, elles sont toutes documentées mais quand même. Vous savez, même si vous documentez quelque chose que les gens ne devraient pas faire, ils le feront quand même. Et vous devrez les diriger vers la documentation. Personne ne lit la documentation d'ailleurs. Pour une raison quelconque, cela arrive. Tant que vous n’avez pas fait remarquer aux gens, cela n’existe pas dans les documents. Mais ok. Nous vous apprendrons quand même. La réactivité était donc l'une des choses.

Natalia: La performance était la suivante. Vue 2 avait toujours et n'a pas les pires performances, mais nous avions quelques idées sur la façon de rendre Vue plus rapide. Et il y avait aussi un problème pour une partie particulière de notre public, disons, les personnes qui utilisent Vue. C'était TypeScript. Vue 2 en interne a été écrit en Flow, qui est toujours fortement typé, mais taper avec TypeScript était un véritable cauchemar, surtout si vous travaillez avec notre gestion d'état Vuex. C'était encore une fois une grande partie. Et le dernier était, nous avons en quelque sorte manqué la fonctionnalité de la logique abstraite, en termes de composants non pas mais de parties logiques compossibles. Comme les fonctions helpers et ainsi de suite, mais elles doivent également pouvoir inclure l'activité du spectateur. Un bel exemple ici pourrait être React Hooks, à droite, ils vous permettent d'abstraire les parties de la fonctionnalité et cela manquait clairement dans Vue. Et je sais qu'à l'heure actuelle, cela ressemble à "Vous avez volé la fonctionnalité à React." Pas en fait. Je crois que la pollinisation croisée des idées est une partie importante et intéressante de notre écosystème et elle aide également les développeurs à basculer entre les favoris, non?

Natalia: Nous travaillions donc sur ces fonctionnalités principales pour créer la Vue 3 comme version majeure.

Drew: Maintenant, je pense que l'un des avantages d'exister dans un écosystème open source est qu'il y a une multitude d'idées et d'expériences issues de toutes sortes de projets différents, et la possibilité de emprunter ces idées et emprunter l'expérience d'autres projets est vraiment bénéfique et rend tout plus fort, n'est-ce pas?

Natalia: C'est le cas. Je pense que cela fonctionne comme nous appelons une valeur d'itération dans GitLab. Lorsque vous avez une idée, elle n’est jamais parfaite. C'est surtout comme quelque chose de très brut, très codé en dur. Peut-être changer quelque chose, mais ce n’est certainement pas parfait. Et vous avez besoin de quelques itérations sur cette idée pour la rendre vraiment bonne, même pas parfaite, juste bonne. Et cela se produit avec des idées dans l'écosystème. Quelqu'un a une bonne idée, et vous la prenez et l'améliorez de mieux en mieux. Et je parie que bien, il y aura quelque chose qui prendra des idées de Vue, peut-être qu'ils ont déjà pris des idées de Vue, et l'améliorent, et il n'y a rien de mal ici.

Natalia: Je suis fortement contre, comme «vous volez des idées». Ce n'est pas du vol, c'est juste une pollinisation croisée.

Drew: Exactement, ouais. Vous avez mentionné que la migration vers TypeScript, donc Vue 3 elle-même est écrite en utilisant TypeScript maintenant, est-ce exact?

Natalia: Oui, oui. Et croyez-moi, Drew, j'écrivais la documentation, le petit document expliquant comment utiliser Vue avec TypeScript. Et j'étais comme, d'accord, probablement en quelque sorte comme Vue 2. Et j'ai trop compliqué le document si fort que j'avais envie de tout taper explicitement. Ça a l'air bien, tout est tapé. Je peux voir les types, donc mon ts-link est heureux, jusqu'ici tout va bien. Et puis l'un de nos développeurs qui travaillait avec TypeScript, "Vous n'avez pas besoin de faire cela". Comme comment, comment? "Vous n'avez pas besoin de faire de types explicites aux données. Vous lui donnez simplement une valeur initiale et ts-link connaît son numéro. Il est déjà saisi. " Comme, comment ça se fait? «J'ai supprimé 90% des types explicites du document. Il n'y a que deux choses que vous aurez vraiment besoin de taper est le proxy du composant, et les propriétés calculées auront. Ils nécessitent toujours des types de retour. Mais le reste est comme, tapé automatiquement, il suffit d'écrire un composant avec une méthode que nous appelons define component. Et c'est tout. C'est typé. »

Natalia: C'était comme si ça marche. Et pour moi, et j'ai beaucoup travaillé avec Angular dans mon expérience passée, j'ai le syndrome de Stockholm pour TypeScript. Tout doit être tapé explicitement. Je veux dire, si vous avez des types complexes, vous devrez bien sûr écrire des interfaces, mais c'est ainsi que fonctionne TypeScript. Pourtant, il est tellement plus facile de travailler avec TypeScript en ce moment avec Vue 3.

Drew: C'est super, donc c'est un avantage à la fois pour le projet Vue Core et pour les développeurs qui créent des applications à l'aide de Vue car ils peuvent utiliser TypeScript dans leurs applications bien avec Vue maintenant, là où ils ne le pourraient pas avec 2.0, ainsi que n'importe quelle version de 2.0 si facilement. Ceux qui connaissent la communauté Vue savent que le créateur de Vue, Evan You, dirige toujours le projet très activement. Comment fonctionne la Core Team? Comment est-il structuré en ce qui concerne le processus de développement? Ce n'est pas tout Evan n'est-ce pas?

Natalia: C'est une si bonne question Drew, parce que pendant des années, littéralement, les gens parlaient de Vue comme, je cite ceci et je vais avoir l'air dur, mais désolé, c'est comme, «Un cadre d'une personne chinoise, comme le cadre chinois même». Et je veux dire que même avec Vue 1.X, il y avait déjà une équipe et il y avait une grande équipe derrière Vue 2 et une équipe encore plus grande derrière Vue 3. Le fait est que nous avons tous des responsabilités différentes quand nous parlons de Vue.

Natalia : Il y a des gens qui travaillent sur Core, et ce n'est pas seulement Evan lui-même, il fait la plupart du travail sur Vue Core, sans aucun doute, et il dirige également le projet. Mais il y a des gens qui travaillent dans Vue Core, et leurs contributions sont absolument inestimables. Et il y a quelques nouvelles personnes, qui rejoignent également l'équipe Vue, qui travaillent dans Core. Et il y a aussi des équipes plus petites qui travaillent sur l'écosystème, il y a des gens qui travaillent sur le Pure Router, comme Eduardo, il y a des gens qui travaillent sur Vue CLI, sur Vuex, sur la documentation aussi.

Natalia: Il y a un toute l'équipe qui travaille sur la documentation parce que nous pensons que la documentation est importante. Et actuellement, sur notre site Web, il y a, je pense, 21, 20 ou 21 personnes, qui manquent toujours le décompte, qui appartiennent à l'équipe de base, mais ce n'est pas une liste statique. Parce que nous, nous n’embauchons évidemment pas, nous sommes une équipe open source, ce n’est pas un travail rémunéré. Mais nous pensons que si quelqu'un contribue beaucoup à l'une des parties de l'écosystème Vue, alors que les gens font déjà le travail du membre de l'équipe Core, c'est juste, en leur donnant une reconnaissance avec un simple accès aux référentiels et au titre officiel.

Drew : C'est génial parce que c'est un cas où contribuer à un projet open source peut en quelque sorte rapporter à un individu. Ils obtiennent une certaine reconnaissance et cela peut avoir un impact sur votre carrière professionnelle et ce que vous avez.

Drew: Pour les auditeurs qui ne sont peut-être pas habitués à Vue mais qui sont peut-être familiers avec d'autres cadres réactifs, comme vous savoir React, Angular et ainsi de suite. Quels sont les grands changements de titre avec Vue 3 et quels problèmes essaient-ils de résoudre en particulier? Vous avez mentionné plus tôt la composition comme l'une de ces choses, est-ce l'un des grands changements?

Natalia: Oui, c'est l'un des plus grands changements, et c'est en fait l'un des éléments qui sont, tout d'abord, comme laissez-moi faire une déclaration claire ici. L'API de composition est purement additive. Ce n’est pas que vous ayez besoin de réécrire vos composants, vous pouvez leur ajouter du TypeScript. Ou vous préférerez peut-être, pour utiliser toute la syntaxe, maintenant nous l'appelons Options API, et rien ne changera pour vous dans ces termes. C'est comme si, lorsque nous parlons de la nouvelle API, il ne s'agit pas d'un changement radical. Je veux juste souligner cela vraiment, c'est vraiment important de dire parce que quand il a annoncé pour la première fois l'API de composition, c'était un moment terrible.

Natalia: Je pense que nous n'avons pas vraiment décrit les changements bien et nous l'avons fait semble que la version standard sera l'API de composition. C’est complètement notre problème et les options étaient comme, peut-être que nous le rendrons obsolète dans les futures versions, pas dans Vue 3, clairement. Et s'il y a des chances que les gens lisent mal ce que vous avez dit, ils le liront mal.

Natalia: Immédiatement après cette déclaration, c'est RFC où nous venons de proposer le changement, Reddit a explosé. Reddit était plein de genre: «Oh, mon dieu. J'aurai besoin de tout écrire. Oh mon Dieu. Vue est nouveau Angular. Ils vont tout casser. » Et il y avait un gars qui a créé un article sur dev.to intitulé, Vue’s Darkest Day. C'était un jour le plus sombre, honnêtement. Nous le pensions, mais j'essayais en quelque sorte de lutter contre cela sur mon propre Twitter du genre: «Des gens que nous ne sommes pas vraiment… Ils disaient que nous avons commencé à changer le RFC, je pense qu'Evan a commencé à changer le RFC sans annoncer de changements. Alors il m'a dit: «Je vais juste réécrire rapidement ceci. Soyons comme pousser vers le maître ». Les gens étaient fous de ça. Parce qu'ils se disputaient sur certains points, il vous suffit de rafraîchir une page et ces points n'existent plus. Vous vous sentez comme si je suis un imbécile ou juste… Qu'est-ce que c'est? Je veux dire, c'était juste là. Je me rappelle de ça. Et je crois que notre stratégie de communication pourrait être meilleure et ce n’est pas nous.

Natalia: En ce moment, chaque fois que je parle de composition, c’est purement additif, les gens. C'est juste une fonctionnalité intéressante. Vous pouvez l'utiliser, vous ne pouvez pas l'utiliser, vous n'êtes pas obligé de le faire. Juste… Cela existe.

Drew: Quel est le genre de problème dans lequel quelqu'un pourrait se retrouver là où l'API de composition est une nouvelle chose qui les aide à sortir de ce problème? Quel problème résout-il?

Natalia: Imaginez le composant qui a quelques caractéristiques à l'intérieur. Disons qu'il s'agit de recherche et de tri. Supposons que nous recherchions une certaine liste et que nous essayions de la trier. Il s'agit déjà de deux fonctionnalités différentes et le problème avec les composants Vue est qu'ils sont divisés en fonction des options et non en fonction de la logique. Imaginez que votre recherche comporte probablement une requête, car vous devez effectuer une requête pour rechercher et afficher un tableau de résultats. Et ce sont deux propriétés réactives. En termes de votre composant, vous les mettez dans l'option qui s'appelle data. Et évidemment, vous avez besoin d'une méthode pour effectuer le tri. Peut-être un clic sur un bouton, peut-être autre chose, quelque chose qui lance la recherche. Vous créez la méthode. Et pour le tri, vous devez construire quelque chose sur les options de tri, une autre propriété réactive. Ensuite, vous effectuez un calcul pour trier les résultats.

Natalia: Dans Vue, pour cela, vous avez également des propriétés calculées, ce qui est une autre option. À la fin, votre composant est devenu vraiment fragmenté. Et imaginez que je suis un développeur et que j'ai une tâche à travailler uniquement sur la recherche d'une partie. Je ne peux pas diviser le composant pour le moment, car ces deux caractéristiques sont en quelque sorte croisées. Je recherche des résultats et les trie. Et j'ai besoin de passer des données à la méthode, de la méthode au calcul et à la fin, il est vraiment difficile de changer de contexte. Surtout si le composant devient vraiment grand.

Natalia: Quelles options avions-nous dans Vue 2.0? La première option s'appelait mixins et mixin est juste un objet qui peut contenir les mêmes propriétés que le composant peut avoir et nous les mélangons avec un composant. Ça a l'air bien, je peux simplement déplacer toute ma recherche là-dedans et quel est le problème? Il y a un peu. Premièrement, ce n'est pas du tout flexible. Si je veux rechercher un certain point final et que je le déplace vers mixin, ce sera le seul point final que je pourrai rechercher. Les mixins n'acceptent pas les paramètres. J'ai créé un mixin, c'est complètement statique. Le deuxième problème est que le mixin est mélangé, ce qui signifie que pour certaines propriétés, cela se produit comme une fusion. Par exemple, si vous avez créé des hooks, ils seront fusionnés. Toute la logique du hook de cycle de vie du composant mixin est fusionnée. Mais si vous avez une propriété de données, une requête à froid dans le mixin et par hasard vous avez la même chose dans le composant, le composant a une priorité. Il sera annulé. Vous n'aurez aucun avertissement. Absolument. Cela arrivera simplement et vous n'aurez aucune idée de ce qui s'est produit.

Drew: Toute la portée est complètement mélangée?

Natalia: Oui, complètement. Il n'y a aucune chance que vous voyiez et aussi, les mixins sont une source très peu claire. Il vous suffit d’importer le mixin avec le nom et de le placer pour afficher la propriété du composant mixin, c’est tout. C'est très implicite et j'en parle du point de vue de ma propre expérience. Nous avons une logique dans GitLab où un composant contient deux mixins et chacun de ces deux mixins contient un autre mixin. Et voilà, voici une propriété que vous devez vérifier et qui n’est pas dans le composant. Allons plus loin, mixin de premier niveau. Celui-ci ne le contient pas et celui-ci ne le contient pas non plus. Où est-ce que c'est? Vous plongez profondément, juste plus profondément dans le terrier du lapin, juste pour trouver cette propriété et les tests deviennent également un cauchemar.

Natalia: Les mixins sont des moyens très, disons, stupides d'extraire la logique. C’est clair, c’est clair, c’est très facile à obtenir. Cela vous pose tellement de problèmes si vous voulez travailler avec cela à un niveau avancé. La prochaine façon d'abstraire la logique dans Vue 2.0 était les composants sans rendu. Dans Vue, le composant peut contenir un slot. Fondamentalement, une pièce où vous pouvez mettre n'importe quoi du composant parent. Une petite fenêtre, une fente en fait. Et il y a une idée de créneaux horaires. Imaginez le composant enfant qui peut exposer sa propre portée au parent et le contenu de l'emplacement y aura accès. Imaginez que j'ai un composant avec un slot et que le composant exécute toute la logique concernant la recherche, disons la recherche qui a un point final avec des paramètres passés. Notre composant enfant, comme la recherche, puis il expose cette partie de sa portée au parent. Ce sont des résultats de recherche. Prendre plaisir. Ça m'a l'air bien. Sonne définitivement mieux que les mixins. Nous pouvons tester les paramètres. La logique est ici explicite, nous retournons quelque chose. Problèmes? Il y en a quelques-uns.

Natalia: Tout d'abord, vous avez créé votre instance de composant. Ce n'est pas l'opération la moins chère au monde. Deuxième partie, c'est l'exécution. Le composant ne fonctionne qu'au moment de l'exécution et cela signifie que la propriété exposée de ce composant ne sera disponible que dans l'emplacement où vous l'avez exposée en tant qu'étendue d'emplacements, de sorte que les résultats de votre recherche ne sont disponibles que dans la petite partie de votre modèle. Si vous souhaitez jouer avec la partie discrète du composant, vous n’y avez pas accès. C'est le temps d'exécution. Il n'y avait pas à appliquer cette logique si vous aviez besoin d'un état réactif ailleurs. Bien sûr, il peut créer une aide comme une fonction pure et renvoyer des résultats, mais que faire si je dois opérer pour les propriétés réactives? C'est ainsi que l'API Composition a été créée. Avec l'API de composition, vous pouvez avoir un état réactif autonome. L'état réactif ne fait plus seulement partie du composant. Vous pouvez rendre réactif n'importe quel objet ou primitif. Et vous pouvez l'exposer au parent, c'est très explicite.

Natalia: Chaque propriété que vous souhaitez rendre au parent est exposée. C'est explicite, vous pouvez cliquer dessus, vous pouvez voir où il se trouve, ce que c'est, etc. Et la meilleure partie, si vous incluez la partie de l'API de composition à un vieux bon composant qui a des méthodes de données, des propriétés informatiques, peu importe, cela fonctionne. Cela fonctionne parfaitement, il vous suffit d'ajouter quelques propriétés et méthodes réactives à votre composant et vous pouvez également les utiliser avec l'ancienne API d'options.

Drew: Cela semble vraiment aider les développeurs à nettoyer leur code bases lorsqu'il s'agit de composants très complexes ou même d'une combinaison légèrement complexe de composants. Et vous avez mentionné la testabilité des mixins et autres, est-ce que l'API de composition permet une meilleure testabilité?

Natalia: Oui, certainement parce que l'API de composition, si nous en excluons les hooks de cycle de vie, car vous pouvez également exécuter un autre hook de cycle de vie dans le composable. C'est en fait une fonction pure. Vous avez des paramètres S, vous faites quelque chose et en dehors des hooks de cycle de vie, il y a encore des effets secondaires. Et tester des fonctions pures, comme vous le savez, est probablement la chose la plus simple. C'est juste une boîte noire, vous avez des paramètres S, vous avez quelque chose à renvoyer.

Drew: Cela semble une solution très complète à un problème que je suis sûr que beaucoup de gens construisent des applications plus complexes avec Vue apprécieront. Et cela semble certainement être un très bon moyen d'éliminer le genre de bogues que je sais que peuvent se glisser dans les mixins, où il est très facile d'introduire des bogues, comme vous l'avez mentionné, avec la fusion de la portée et toutes ces sortes de choses. [19659008] Drew: Je pense toujours que la stabilité de l'API au fil du temps est une considération majeure lors du choix de construire sur un framework. Peut-être que la stabilité n'est pas le bon mot, mais je pense que beaucoup d'entre nous ont été piqués en construisant au-dessus d'un cadre puis subissent une grande refonte et nous laisse avec des applications qui nécessitent un investissement massif pour migrer ou qui finissent simplement par être liées à une ancienne version d'un framework qui n'est alors plus supporté. C’est une situation horrible. Combien de temps vais-je perdre en dormant en déplaçant un gros projet de Vue 2 vers Vue 3?

Natalia: Tout d’abord, la surface de l’API est à 90% la même qu’elle était. Nous n'avions pas autant d'éléments obsolètes ou de filtres obsolètes qui peuvent être remplacés par des hubs d'événements obsolètes. Si vous souhaitez utiliser un EventEmitter, vous devez également remplacer un émetteur basé sur une vue par une bibliothèque externe. Ce sont de grands changements, mais en parlant de migration… Permettez-moi de préciser, je suis vraiment déchiré en ce moment, car d'un côté, je suis membre de l'équipe de base de Vue JS. D'autre part, je suis un ingénieur du personnel dans le grand projet qui utilise Vue. Si vous êtes sur le point de commencer la migration maintenant, je ne recommanderais pas de le faire. Tout d'abord, l'écosystème n'est pas publié, je veux dire si nous parlons de bibliothèques de base comme Pure Router, PUX, Vue CLI, elles sont en bonne forme mais elles sont toujours des candidats à la publication, pas des versions. Et si nous parlons d'autres écosystèmes comme peut-être pas les bibliothèques de base, les bibliothèques de composants d'interface utilisateur, peut-être certaines bibliothèques de validation de formulaire, ils ne sont pas prêts, principalement, pour Vue 3. Et si vous avez un gros projet, vous avez tellement de dépendances que vous devez se soucier. Donc, ce sera une chose compliquée.

Natalia: Quelles sont les options? Vous avez un gros projet, vous souhaitez utiliser toute cette bonté de l'API Composition. Comment y parvenir? Tout d'abord, nous prévoyons de publier une version LTS de Vue 2.0, Vue 2.7. Cela inclura de nombreux avertissements de désapprobation, vous pourrez donc voir ce qui va être obsolète, comment le refactoriser pour ne pas le casser avec Vue 3. Donc, vous utiliserez toujours techniquement Vue 2 mais vous préparerez Vue 3 de toute façon parce que vous avez tous les avertissements.

Natalia: Deuxièmement, nous utiliserons un outil de migration qui pourra simplement l'exécuter et il fonctionnera comme un codemod, en remplaçant les éléments liés à Vue 2 par Vue 3 alternatives. Bien sûr, aucun codemod n'est parfait. Nous visons, tout d'abord, à effectuer des remplacements chaque fois que possible, mais également à afficher des avertissements chaque fois que la dépréciation n'est pas facilement gérée. Codemod pourra reconnaître une chose et lancer un avertissement mais pas la remplacer par elle-même. C'est comme un gros plan et au moment où Vue 2.7 sortira et je pense que pour le moment, leur heure d'arrivée estimée est décembre si je me souviens bien, j'aurais besoin de vérifier la feuille de route, mais je pense que c'est décembre.

Natalia: L'écosystème sera également plus ou moins prêt. Si vous avez un gros projet avec Vue 2.0, attendez un peu plus jusqu'à ce que Core soit stabilisé car même si vous produisez une bibliothèque parfaite, il faut encore un peu de temps pour se stabiliser car les gens commencent à l'utiliser, les gens commencent à signaler des bogues. Si vous êtes sur le point de l'utiliser pour un projet animalier et de signaler des bogues, nous vous invitons à le faire. Et après cela, il y aura un bon moyen de migrer vers Vue 3.

Drew: Donc, l'outil de migration que vous avez mentionné semble assez intéressant. Est-ce essentiellement un outil d'analyse statique qui examine votre code et…

Natalia: Oui, oui, oui, c'est un code ou un outil. À l'heure actuelle, il est disponible de manière très limitée. Il est disponible en tant que plug-in de Vue CLI. Si vous avez un projet basé sur Vue CLI, vous pouvez exécuter la mise à niveau de Vue et voir comment l'outil fonctionne. Il n’est pas dans la forme que nous souhaitons pour le moment. Malheureusement, je ne travaille pas sur un projet basé sur Vue CLI. J'aurais besoin d'attendre et de vérifier ce qui se passe mais, par exemple GitHub, nous avons déjà pris quelques mesures même sans outil de migration pour nous préparer, car nous savons ce qui est obsolète. C'est en fait indiqué dans la documentation de Vue 3.

Natalia: Il existe un guide de migration. Vous pouvez voir tous les changements de rupture et les choses qui sont obsolètes et vous pouvez déjà travailler sur une partie d'entre eux, même sur la base de code Vue 2.0. Par exemple, dans Vue 2.6, nous avons changé la syntaxe des slots. La syntaxe des emplacements d'étendue était obsolète mais non refusée, elle existe toujours. Il donne un avertissement mais vous pouvez l'exécuter. Et bien sûr, avec une base de code vieille de sept ans, personne ne se soucie de remplacer toute la syntaxe obsolète si cela fonctionne. Il n'y a pas d'avertissement en production. Les machines à sous fonctionnent. Dans le développement comme, "Oh, je vois un avertissement dans la console. Peut-être 20 d'entre eux, très bien. C'est jaune pas rouge. Je m'en fiche ».

Natalia: Vous savez que cela arrive à tout le monde. Nous avons créé une énorme épopée pour y travailler. Trouvez tous les ensembles actuels de l'ancienne syntaxe. Nous faisons un effort pour remplacer notre EventEmitters, encore une fois, un projet vieux de sept ans, ne nous jugez pas. Nous avons EventEmitters. GitLab travaillait sur EventHubs. Nous avons remplacé le plaisir basé sur Vue par des bibliothèques externes. Je recommanderais de faire de même. Parcourez le guide de migration en vérifiant ce qui peut déjà être remplacé et les modifications que vous pouvez déjà apporter pour vous préparer et commencer à travailler dessus.

Drew: Avec l'état actuel de l'outil de migration, soyez un bon moyen de tester simplement les eaux avec votre base de code. Il suffit de l'exécuter et de jeter un coup d'œil pour voir ce qu'il signale déjà, pour voir si cela semble correct ou s'il y a de grandes choses ou est-il encore immature pour cela? Est-il préférable d’attendre jusqu’en décembre pour pouvoir régler les problèmes.

Natalia: Si j’avais un gros projet, je ne recommanderais pas de le faire. Si vous avez un petit projet défectueux ou peut-être un projet personnel mais qu'il n'est pas si important, je vous recommanderais de l'exécuter et de vérifier les problèmes comme celui que vous avez, car pour deux projets de taille moyenne, je l'ai exécuté. Je pense qu'un ou deux problèmes. Je ne peux pas dire qu’il est immature. Il est déjà en bon état. Mais pour les grands projets encore une fois, c’est un héritage, c’est des trucs exotiques. Ne faites pas cela en production, les gens.

Natalia: Aussi si vous souhaitez jouer avec l'échafaudage de votre projet, pour le moment, Vue CLI prend en charge deux modes. Vous pouvez créer un projet Vue 2, vous pouvez créer un projet Vue 3. Et certainement essayer au moins. C'est un bon moyen pour nous aussi car en jouant, vous découvrez des bogues, vous signalez des bogues, nous essayons de les corriger et ainsi de suite.

Drew: Dans la documentation et sur la feuille de route de développement, je vois la mention d'une version de migration. Est-ce quelque chose de différent de ce dont nous avons parlé ou est-ce de cela dont nous parlons?

Natalia: Non, non, c'est la même chose. C'est le même et il devrait être prêt mais pour l'instant, si vous planifiez la migration, le chemin principal consiste simplement à lire la documentation et à suivre tout ce qui y est dit car nous faisons vraiment un effort chaque fois que nous n'avons pas d'outil de migration, l'équipe de documentation a continué et créé un guide détaillé de ce qui est le changement, pourquoi il a été fait et ce qui est en fait un remplacement ici.

Drew: Oui, dans la documentation est un guide de migration assez complet dans le cadre de la documentation Vue 3 et il mentionne énormément de changements qui nécessitent une migration. Je suppose que certains d’entre eux n’auront aucun impact sur tous les projets. Beaucoup d'entre eux étaient essentiellement des cas extrêmes pour beaucoup de gens. Est-ce juste?

Natalia: Oui, une bonne partie d'entre eux, par exemple, les filtres, sont certainement des cas extrêmes, car même chez GitLab avec, pour la troisième fois, une base de code vieille de sept ans et une grosse. Nous avons eu une ou deux occurrences de filtres et ils n'étaient plus utilisés. C'était une bonne chose que nous les recherchions et les supprimions complètement parce que comme, "Oh, code inutilisé" et encore une fois, peu importe, il existe juste.

Natalia: Je dirais que les changements totalement révolutionnaires sont le modèle changements. Jetez un coup d'œil à cela, car chaque projet que je connais contient au moins un modèle Vue, bien sûr. Cela devrait être vérifié et peut-être que les attributs changeront également car nous incluons actuellement la classe et le style, les tubulaires et les éthers. Et si vous avez déjà travaillé avec Vue, auparavant, il n'était pas inclus. À l'heure actuelle, la façon dont vous transmettez la classe et le style à un composant enfant est légèrement différente et il vaut vraiment la peine de s'y intéresser.

Drew: C'est bon à savoir. Les versions 3.0 fournies avec Vue, je veux dire que vous avez mentionné l'écosystème et tout ce qui l'entoure, Vuex et toutes ces autres parties de l'écosystème qui doivent avancer à ce niveau. Est-ce pourquoi, actuellement, le site Web, le gros bouton «Getting Started» va toujours à Vue 2? On a l'impression que Vue 3 a été publié mais pas en toute confiance. Mais est-ce à cause de ce problème d’écosystème que c’est encore le cas?

Natalia: Non, je pense que vous venez de trouver un bogue, laissez-moi vérifier rapidement. Non, commencer pointe vers Vue 3, ça va. Je veux dire si vous allez sur vuejs.org, cela pointe vers la version deux. C'est intentionnel car nous avons prévu de le remplacer par un sous-domaine comme Vue 2, qui est en cours de travail, mais jusqu'à présent, nous décidons de laisser vuejs.org où il se trouve et de créer Vue 3 et c'est pourquoi il y a une bannière sur vuejs. org. Si vous allez dans n'importe quel document-

Drew: Il y a une toute petite bannière en haut, oui.

Natalia: Oui, comme petite.

Drew: Ouais. [19659009] Natalia: Nous devrions l'agrandir, je suppose. Plus grand et avec un meilleur contraste de couleur. Mes sentiments d’accessibilité restent comme «Oh, il n’ya rien de contrasté».

Drew: C’est une bonne nouvelle. Si quelqu'un commence, peut-être pas un gros projet, mais si quelqu'un démarre un projet personnel ou veut apprendre Vue, certainement, Vue 3 est le point de départ?

Natalia: Je dirais que oui. La courbe d'apprentissage n'est pas si différente d'ailleurs. Parce que l’équipe de documentation avait l’intention d’avoir les anciennes options de syntaxe, je ne devrais pas dire anciennes, c’est en fait la syntaxe actuelle. La syntaxe familière par défaut. Parce que si vous parcourez la documentation de Vue 3, vous ne verrez avec l'API Composition que dans les sujets avancés et le chemin d'apprentissage que vous avez avec Vue 3 est un peu similaire à ce que vous aviez dans Vue 2. Il n'y a pas grand chose à commencer avec un plus récent version si vous venez d'apprendre Vue et essayez de l'expérimenter et je pense que ce serait un meilleur investissement si nous parlons de carrière. Commencez à apprendre la version la plus récente car elle dépassera tous les projets. Finalement, peut-être une demi-année, une année, même pour des projets de grande envergure, il y aura migration.

Drew: Il me semble avoir dans ma carrière personnelle, un vrai talent de venir sur les plateformes tout comme elles dans le processus d'une grande migration. Je veux dire même aussi loin que, vous vous en souvenez, Macromedia Director, en remontant aussi loin et Shockwave, Flash et tout ce genre de choses. J'y suis arrivé alors qu'ils passaient à la syntaxe des points et j'ai dû apprendre les deux. Et me voilà, je me retrouve le mois dernier à travailler sur un projet dans Vue pour la première fois, qui est un projet Vue 2 et à apprendre au fur et à mesure et j'ai hâte de voir tout ce qui va arriver dans Vue 3. C'est C'est certainement un moment intéressant pour apprendre quelque chose au fur et à mesure qu'il migre, mais il semble que ce n'est pas trop difficile avec Vue et une fois que l'écosystème a rattrapé le noyau, nous devrions être au bon endroit.

Natalia: Oh, Drew, je veux juste faire un point sur tout ce que vous avez dit au sujet des grands projets d'immigration. You can imagine me like, 2018 and I’m joining GitLab. I wasn’t Core Team members, I’m just a contributor at this moment.

Natalia: Immediately the same time Evan is like, “Oh,we are going to make Vue 3”. Everyone like, “Yeah, cool”. Spring of 2019 you are the Core Teeam. I mean the whole GitLab is like, “Oh, this is cute. We all having migration and you know who is kind of responsible for this?” And you can only imagine how it happens when you write documentation for Vue 3, everybody will be reading and your own company is like, “Oh, I want to learn something about Vue 3, I can’t understand your docs.” So you’re like, “Oh, damn this is so painful” because you’re a developer there and tech writer, kind of here.

Natalia: You’re in the middle of this but, I have to say it’s really beneficial for framework as well because any big product created with a framework is a great, absolutely great battlefield to find bugs and bring them back to the library, to the ecosystem. I can say that tests, and GitLab is open sourced, Vue Test Utils, which is a testing tool for Vue. A team was using our testing code based around tests, which makes a lot of sense, right. Because you can find some edge cases and so on. But still, when I think about migrating GitLab to Vue 3, I feel like a personal responsibility for this. I’m not only in the middle of migration, I’m personally responsible for every single bug we will find.

Drew: Looking back at the previous generation of JavaScript frameworks, I think one of the most successful of those was jQuery, back in the day, and I think it gained traction because it had an extremely well designed API. Just this concept of taking a CSS selector and using it to query the DOM in your JavaScript was something that jQuery popularized. 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.

Drew: It really is.

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.

(il)