Smashing Podcast Episode 26 avec Natalia Tepluhina : Quoi de neuf dans Vue 3.0 ?

Dans cet épisode de podcast, nous parlons de VueJS. Quelles sont les nouveautés de 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 remarques

• VueJS
• Le guide de migration de Vue 3
• Natalia sur Twitter
• Site personnel de Natalia

Mise à jour hebdomadaire

• Différentes façons de concevoir des pages de produits numériques
  écrit par Suzanne Scacca
• Tests unitaires dans les applications natives React
  écrit parFortune Ikechi
• 5 façons dont Google Analytics aide les développeurs Web dans la conception UI/UX
  écrit par Clara Buenconsejo
• Comprendre les génériques TypeScript
  écrit par Jamie Corkhill
• Comment utiliser Face Motion pour interagir avec la typographie
  écrit par Edoardo Cavazza

Transcription

Drew McLellan : c'est une développeur Web passionnée, une experte en développement Google, ainsi qu'une conférencière et auteure. Elle est actuellement ingénieure de front chez GitLab, mais vous la connaissez peut-être mieux en tant que membre de l'équipe Vue JS Core. Il est donc clair qu'elle connaît son chemin dans Vue mieux que presque n'importe qui. Mais saviez-vous qu'elle a déjà appris à chanter à un kangourou. Mes amis Smashing, veuillez accueillir Natalia Tepluhina.

Drew : Salut Natalia, comment vas-tu ?

Natalia Tepluhina : Salut Drew, c'était une très belle tentative sur mon nom de famille. Je dois te donner des crédits. C'était l'une des meilleures choses que j'ai 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. Sa prononciation correcte est Tepluhina, mais c'est comme ça, c'est pourquoi je demande généralement aux gens de m'appeler Natalia et arrêtons-nous là.

Drew : D'accord, eh bien j'ai fait un effort. Mais la question importante est, êtes-vous Smashing?

Natalia : Bien sûr que je le suis.

Drew : C'est bien. Je voulais donc vous parler aujourd'hui de 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'est-ce 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, c'était au printemps, le vrai travail a commencé à l'automne 2018. Et je pense que cela a été officiellement annoncé lors de la conférence de Londres, qui a eu lieu en octobre 2018. Le travail actif a duré deux ans. Et c'est beaucoup si vous y réfléchissez, la version précédente est sortie en 2016. La moitié de ces quatre années a donc également été consacrée au travail de Vue 3.

Drew : Quel était le genre de facteur de motivation pour décider qu'une nouvelle version majeure était nécessaire ? É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écessitait 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 choses très importantes. 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 auriez besoin de les pointer vers la documentation. Personne ne lit la documentation d'ailleurs. Pour une raison quelconque, cela arrive. Jusqu'à ce que vous signaliez aux gens qu'il n'existe pas dans les documents, c'est le cas. 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 avons eu quelques idées sur la façon de rendre Vue plus rapide. Et il y avait aussi un point douloureux pour une partie particulière de notre, disons, public, les gens qui utilisent Vue. C'était TypeScript. Vue 2 a été écrit en interne en Flow, qui est encore 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 partie énorme. Et le dernier était, nous avons en quelque sorte manqué la fonctionnalité de la logique abstraite, en termes non pas de composants mais de parties logiques compossibles. Comme les assistants de fonctions, etc., mais ils devraient également pouvoir inclure l'activité des spectateurs. 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'en ce moment, cela ressemble à "Vous avez volé la fonctionnalité de React". Pas en fait. Je crois que la pollinisation croisée des idées est une grande et belle partie de notre écosystème et aide également les développeurs à basculer entre les favoris, n'est-ce pas ?

Natalia : Nous avons donc travaillé sur ces fonctionnalités principales pour créer la Vue 3 en tant que version majeure.

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

Natalia : Ça l'est. Je pense que cela fonctionne comme nous appelons une valeur d'itération dans GitLab. Quand vous avez une idée, elle n'est jamais parfaite. C'est surtout 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 arrive avec des idées dans l'écosystème. Quelqu'un vient avec une bonne idée, et vous la prenez et la rendez 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élioreront, et il n'y a rien de mal ici.

Natalia : Je suis fortement contre, genre « tu voles des idées ». Ce n'est pas du vol, c'est juste de la pollinisation croisée.

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

Natalia : Oui, oui. Et croyez-moi, Drew, j'écrivais la documentation, le petit document sur l'utilisation de Vue avec TypeScript. Et j'étais comme, d'accord, probablement comme Vue 2. Et j'ai tellement compliqué le document que j'avais l'impression de tout taper explicitement. Ça a l'air bien tout est tapé. Je peux voir les types, donc mon lien ts 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 ça". Comme comment, comment ? « Vous n'avez pas besoin de faire des types explicites aux données. Vous lui donnez juste une valeur initiale et ts-link connaît son numéro. C'est déjà tapé. 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, c'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 tapé.

Natalia : C'était comme si ça fonctionnait. 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 : Donc c'est génial, 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 désormais utiliser TypeScript dans leurs applications avec Vue, alors qu'ils ne le pouvaient pas avec la version 2.0, enfin 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 excellente question, Drew, car pendant des années, littéralement, les gens ont parlé de Vue, je cite ceci et je vais paraître dur, mais désolé, c'est comme : "Un cadre d'une personne chinoise, comme un 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 lorsque 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, certainement, 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, rejoignant é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 routeur pur, comme Eduardo, il y a des gens qui travaillent sur Vue CLI, sur Vuex, sur la documentation également.

Natalia : Il y a toute une équipe qui travaille sur la documentation car 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 au décompte, qui appartiennent à l'équipe Core, mais ce n'est pas une liste statique. Parce que nous, nous n'embauchons pas évidemment, 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, lorsque les gens font déjà le travail du membre de l'équipe principale, c'est juste, leur donnant une reconnaissance avec juste un 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 vraiment rapporter à un individu. Ils obtiennent une certaine reconnaissance et cela peut avoir un impact sur votre carrière professionnelle et ainsi de suite.

Drew : Pour les auditeurs qui ne sont peut-être pas habitués à Vue, mais qui connaissent peut-être d'autres frameworks réactifs, tels que React, Angular, etc. Quels sont les gros changements avec Vue 3 et plus précisément quels problèmes essaient-ils de résoudre ? Vous avez mentionné la composition plus tôt 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'une des choses qui sont, tout d'abord, comme permettez-moi de 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 TypeScript. Ou vous préférerez peut-être utiliser toute la syntaxe, maintenant nous l'appelons Options API, et rien ne changera pour vous dans ces termes. C'est comme si, quand on parle de nouvelle API, ce n'est pas un changement radical. Je veux juste souligner cela vraiment, c'est vraiment important de le dire parce que quand il a annoncé l'API de composition pour la première fois, c'était un moment terrible.

Natalia : Je pense que nous n'avons pas vraiment bien décrit les changements et nous avons fait croire que la construction standard sera l'API de composition. C'est complètement notre problème et les options étaient comme, peut-être que nous le déconseillerons 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'était RFC où nous venons de proposer le changement, Reddit a explosé. Reddit était plein de genre, "Oh, mon dieu. Je vais devoir tout écrire. Oh mon Dieu. Vue est le 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. Ce fut une journée des plus sombres, honnêtement. Nous l'avons ressenti, mais j'essayais de lutter contre cela sur mon propre Twitter, du genre: «Les 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 s'est dit : « Je vais juste réécrire ça rapidement. Commençons par pousser dans le maître ». Les gens étaient fous de ça. Parce qu'ils se disputaient sur certains points, vous venez de rafraîchir une page et ces points n'existent plus. Vous vous dites, suis-je un imbécile ou juste… Qu'est-ce que c'est que ça ? 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'y êtes pas obligé. Juste… Il existe.

Drew : Dans quel type de problème quelqu'un pourrait-il se retrouver alors que l'API de composition est une nouveauté qui l'aide à résoudre ce problème ? Quel problème résout-il ?

Natalia : Imaginez le composant qui contient quelques fonctionnalités. Disons que c'est la recherche et le tri. Disons que nous recherchons une certaine liste et que nous essayons 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 ait probablement une requête, car vous devez faire une requête pour rechercher et un tableau de résultats. Et ce sont deux propriétés réactives. En ce qui concerne votre composant, vous les placez dans l'option appelée data. Et évidemment, vous avez besoin d'une méthode pour effectuer le tri. Peut-être un clic sur un bouton, peut-être quelque chose d'autre, quelque chose qui lance la recherche. Vous créez la méthode. Et pour le tri, vous devez créer 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 pour tâche de travailler uniquement sur la partie recherche. Je ne peux pas diviser le composant pour le moment, car ces deux fonctionnalités sont en quelque sorte croisées. Je recherche des résultats et je 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 simplement changer de contexte. Surtout si le composant devient vraiment gros.

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élangeons 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. Tout d'abord, ce n'est absolument pas 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, il est complètement statique. Le deuxième problème est que 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 crochets, 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 que par hasard vous avez la même chose dans le composant, le composant a une priorité. Il sera remplacé. Vous n'aurez aucun avertissement. Absolument. Cela arrivera simplement et vous n'aurez aucune idée que cela 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 le voyiez et aussi, les mixins sont une source très peu claire. Vous venez d'importer le mixin avec le nom et de le mettre pour afficher le mixin de la propriété du composant, 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 n'en contient pas et celui-ci n'en 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, permettez-moi de dire, des manières stupides d'extraire la logique. C'est clair, c'est clair, c'est très facile à obtenir. Cela vous apporte 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, un 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 slots délimités. Imaginez que le composant enfant qui peut exposer sa propre portée au parent et au contenu de l'emplacement y ait accès. Imaginez que j'ai un composant avec un slot et que le composant exécute toute la logique concernant la recherche, disons une 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 a l'air bien. Sonne certainement mieux que les mixins. Nous pouvons tester les paramètres. La logique est explicite ici, nous retournons quelque chose. Questions? Il y a un peu.

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'à l'exécution, ce qui signifie que la propriété exposée de ce composant ne pourra être utilisée que dans l'emplacement où vous l'avez exposée en tant qu'étendue d'emplacements, de sorte que vos résultats de recherche ne sont disponibles que dans la petite partie de votre modèle. Si vous voulez jouer avec la partie discrète du composant, vous n'y avez pas accès. C'est l'exécution. Il n'y avait pas d'action à 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 se passe-t-il si j'ai besoin d'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 n'importe quel objet ou primitif réactif. Et vous pouvez l'exposer au parent, c'est très explicite.

Natalia : Chaque propriété que vous souhaitez rendre à vos parents est exposée. C'est explicite, vous pouvez cliquer dessus, vous pouvez voir où c'est, ce que c'est, et ainsi de suite. Et la meilleure partie, si vous incluez la partie de l'API de composition à l'ancien 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 leurs bases de code lorsqu'il s'agit de composants très complexes ou même de combinaisons de composants légèrement complexes. Et vous avez mentionné la testabilité des mixins et autres, l'API Composition permet-elle une meilleure testabilité ?

Natalia : Oui, certainement parce que l'API de composition, si nous excluons les crochets de cycle de vie, car vous pouvez également exécuter un autre crochet 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 crochets du 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 à retourner.

Drew : Cela semble être une solution très complète à un problème que, j'en suis sûr, beaucoup de gens qui créent des applications plus complexes avec Vue apprécieront. Et cela semble certainement être un très bon moyen d'éliminer le genre de bogues qui, je le sais, peuvent s'infiltrer avec 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.

Drew : Je pense toujours que la stabilité de l'API dans le temps est une considération majeure lorsque l'on choisit de construire au-dessus d'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 subit un gros remaniement et nous laisse avec des applications qui nécessitent un investissement massif pour migrer ou qui finissent par être liées à une ancienne version d'un framework qui n'est alors plus supporté. C'est une situation horrible. Combien de sommeil vais-je perdre en déplaçant un gros projet de Vue 2 à Vue 3 ?

Natalia : Tout d'abord, la surface de l'API est à 90 % la même qu'avant. Nous n'avions pas beaucoup de choses 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 devrez également remplacer une vue basée sur une bibliothèque externe. Ce sont de grands changements, mais en parlant de migration… Laissez-moi être clair, je suis vraiment déchiré en ce moment, car d'une part je suis membre de Vue JS Core Team. D'un autre côté, je suis un ingénieur du personnel dans le grand projet qui utilise Vue. Si vous êtes sur le point de commencer la migration dès maintenant, je vous déconseille 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 ce sont toujours des versions candidates, pas des versions. Et si nous parlons d'autres écosystèmes comme les bibliothèques non centrales peut-être, les bibliothèques de composants d'interface utilisateur, peut-être certaines bibliothèques de validation de formulaire, elles ne sont pas prêtes, pour la plupart, pour Vue 3. Et si vous avez un gros projet, vous avez tellement de dépendances que vous devez se soucier. Ce serait donc une chose compliquée.

Natalia : Quelles sont les options ? Vous avez un gros projet, vous voulez utiliser toutes ces qualités 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 d'obsolescence, 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 qui fonctionnera comme un codemod, remplaçant les éléments liés à Vue 2 par des alternatives Vue 3. Bien sûr, aucun mod de code n'est parfait. Notre objectif est, tout d'abord, d'effectuer des remplacements chaque fois que possible, mais également d'afficher des avertissements chaque fois que la dépréciation n'est pas facilement gérée. Codemod sera capable de reconnaître une chose et de lancer un avertissement mais pas de la remplacer par elle-même. C'est comme un grand plan et au moment où Vue 2.7 est sorti et je pense qu'en ce moment leur heure d'arrivée estimée est décembre si je me souviens bien, je devrais vérifier la feuille de route, mais je pense que c'est décembre.

Natalia : L'écosystème sera aussi plus ou moins prêt. Si vous avez un gros projet avec Vue 2.0, attendez juste un peu plus jusqu'à ce que Core soit stabilisé car même si vous produisez une bibliothèque parfaite, elle a encore besoin 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 familier et signaler des bogues, s'il vous plaît, vous êtes les bienvenus. 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. Ce n'est pas dans la forme que nous voulons qu'il soit jusqu'à présent. Malheureusement, je ne travaille pas sur un projet construit sur Vue CLI. Je devrais attendre et vérifier ce qui se passe mais, par exemple GitHub, nous avons déjà franchi quelques étapes même sans outil de migration pour nous préparer, car nous savons ce qui est obsolète. C'est en fait indiqué sur la documentation de Vue 3.

Natalia : Il y a un guide de migration. Vous pouvez voir tous les changements de rupture et les éléments 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 modifié la syntaxe des slots. La syntaxe des emplacements de portée était obsolète mais pas 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 elle fonctionne. Il n'y a pas d'avertissement en production. Les machines à sous fonctionnent. En 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 : Tu sais que ça arrive à tout le monde. Nous avons créé une énorme épopée pour travailler là-dessus. Trouvez tous les ensembles actuels de l'ancienne syntaxe. Nous nous efforçons de remplacer nos EventEmitters, encore une fois, 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 la même chose. 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, c'est un bon moyen de simplement tester 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 s'il semble correct ou s'il y a de grandes choses ou est-ce encore trop immature pour cela ? Est-il préférable d'attendre jusqu'en décembre quand il pourrait effectivement être en mesure d'arranger les choses.

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

Natalia : De plus, si vous souhaitez jouer avec l'échafaudage de votre projet, Vue CLI prend actuellement 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 au fur et à mesure que vous jouez, vous découvrez des bugs, vous signalez des bugs, nous essayons de les corriger, etc.

Drew : Dans la documentation et sur la feuille de route de développement, je vois une 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 pareil. C'est le même et il devrait être prêt mais pour l'instant, si vous planifiez la migration, le chemin principal est simplement de lire les documents et de 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 est allée de l'avant et créé un guide détaillé de ce qu'est le changement, pourquoi il a été fait et ce qui est réellement un remplacement ici.

Drew : Oui, dans la documentation se trouve un guide de migration assez complet dans le cadre de la documentation de Vue 3 et il mentionne énormément de changements qui doivent être migrés. Je suppose que certains d'entre eux n'auront pas d'incidence sur tous les projets. Beaucoup d'entre eux étaient essentiellement des cas marginaux pour beaucoup de gens. Est-ce juste?

Natalia : Oui, une bonne partie d'entre eux, par exemple, les filtres, sont définitivement des cas extrêmes parce que 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 ayons recherchés et que nous les ayons complètement supprimés parce que, par exemple, "Oh, code inutilisé" et encore une fois, peu importe qu'il existe.

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

Drew : C'est bon à savoir. Les versions 3.0 qui sont publiées 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 passer à ce niveau. Est-ce la raison pour laquelle, actuellement, sur le site Web, le gros bouton "Getting Started" va toujours à Vue 2 ? C'est un peu comme si Vue 3 était sorti mais pas en toute confiance. Mais est-ce à cause de ce problème d'écosystème que c'est toujours comme ça ?

Natalia : Non, je pense que vous venez de trouver un bogue, laissez-moi vérifier rapidement. Non, commencer pointe vers Vue 3, c'est bon. Je veux dire, si vous allez sur vuejs.org, cela pointe vers la version deux. C'est intentionnel car nous avions prévu de le remplacer par un sous-domaine comme Vue 2, qui est en cours de développement, mais jusqu'à présent, nous avons décidé 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 à n'importe quel doc-

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

Natalia : Oui, comme petite.

Drew : Ouais.

Natalia : Nous devrions l'agrandir, je suppose. Plus grand et avec un meilleur contraste de couleurs. Mes sentiments d'accessibilité restent du genre "Oh, il n'y a rien de contrasté là-bas".

Drew : C'est une bonne nouvelle. Si quelqu'un démarre, 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 d'ailleurs pas si différente. 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 de composition que dans les sujets avancés et le parcours 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 nouveau version si vous venez d'apprendre Vue et essayez de l'expérimenter et je pense que ce serait un meilleur investissement si nous parlions de carrière. Commencez à apprendre la nouvelle version car elle dépassera tous les projets. Finalement, peut-être une demi-année, un an, même pour les projets de grande taille, il y aura une migration.

Drew : J'ai l'impression d'avoir, dans ma carrière personnelle, un réel talent pour venir sur les plateformes au moment même où elles sont en train d'effectuer une grande migration. Je veux dire aussi loin que, souvenez-vous, Macromedia Director, remontant aussi loin et Shockwave, Flash et tout ce genre de choses. J'y suis arrivé alors qu'ils passaient à la syntaxe à points et j'ai dû apprendre les deux. Et me voilà, je me retrouve le mois dernier à travailler pour la première fois sur un projet dans Vue, qui est un projet Vue 2 et à apprendre au fur et à mesure et j'attends avec impatience toutes les choses qui arrivent dans Vue 3. 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 Core, nous devrions être bien placés.

Natalia : Oh, Drew, je veux juste faire une remarque sur ce que vous avez dit sur les grands projets d'immigration. Vous pouvez m'imaginer comme, 2018 et je rejoins GitLab. Je n'étais pas membre de la Core Team, je suis juste un contributeur en ce moment.

Natalia : Immédiatement au même moment, Evan se dit : « Oh, nous allons faire Vue 3 ». Tout le monde aime "Ouais, cool". Printemps 2019, vous êtes le Core Team. Je veux dire que tout le GitLab est comme, "Oh, c'est mignon. Nous avons tous des migrations et vous savez qui est en quelque sorte responsable de cela ? » Et vous ne pouvez qu'imaginer comment cela se passe lorsque vous écrivez de la documentation pour Vue 3, que tout le monde lira et que votre propre entreprise se dira : « Oh, je veux apprendre quelque chose sur Vue 3, je ne comprends pas vos documents. Alors vous vous dites "Oh, putain, c'est tellement douloureux" parce que vous êtes développeur là-bas et rédacteur technique, en quelque sorte ici.

Natalia : Vous êtes au milieu de tout cela, mais je dois dire que c'est également très bénéfique pour le framework, car tout gros produit créé avec un framework est un formidable champ de bataille pour trouver des bogues et les ramener à la bibliothèque, pour l'écosystème. Je peux dire que les tests, et GitLab est open source, Vue Test Utils, qui est un outil de test pour Vue. Une équipe utilisait notre code de test basé sur des tests, ce qui a beaucoup de sens, n'est-ce pas. Parce que vous pouvez trouver des cas extrêmes et ainsi de suite. Mais quand même, quand je pense à migrer GitLab vers Vue 3, je me sens personnellement responsable de cela. Je ne suis pas seulement au milieu de la migration, je suis personnellement responsable de chaque bogue que nous trouverons.

Drew : En regardant la génération précédente de frameworks JavaScript, je pense que l'un des plus réussis était jQuery, à l'époque, et je pense qu'il a gagné du terrain parce qu'il avait une API extrêmement bien conçue. 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 : C'est vraiment le cas.

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.