Catégories
Plugin et site web

Quoi de neuf dans Vue 3.0? – Magazine Smashing

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.

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

Photo de Natalia TepluhinaDrew McLellan: Elle est une développeur Web passionnée, une experte en développement Google, une conférencière et une auteure. 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 accueillir Natalia Tepluhina.

A dessiné: 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à.

A dessiné: Ok, eh bien j'ai fait un effort. Mais la question importante est, est-ce que vous Smashing?

Natalia: Bien sur que je le suis.

A dessiné: C'est bon. 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’est-ce pas le moment?

Natalia: Il 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 y réfléchissez, 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.

A dessiné: Quel a été le type 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é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 qu'elle aide également les développeurs à basculer entre les favoris, non?

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

A dessiné: Maintenant, je pense que c'est l'un des avantages d'exister dans un écosystème open source, c'est qu'il y a une richesse d'idées et d'expériences 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: Il est. 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 fermement contre, comme "Vous volez des idées". Ce n'est pas du vol, c'est juste une pollinisation croisée.

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

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 tapé. »

Natalia: C'était comme, ç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 dès maintenant avec Vue 3.

A dessiné: Donc c'est génial, c'est donc 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 bien utiliser TypeScript dans leurs applications avec Vue maintenant, là où ils ne le pourraient pas avec 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, non?

Natalia: C’est une très bonne question à Drew, car pendant des années, littéralement, les gens parlaient de Vue comme, je le cite et je vais sembler dur, mais désolé, c’est comme: «Un cadre d’une personne chinoise, comme le cadre chinois même». Et je veux dire, 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, certainement, et il dirige le projet aussi. 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 également.

Natalia: Il y a toute une é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 formel.

A dessiné: C’est formidable, car c’est un cas où la contribution à un projet open source peut en quelque sorte rapporter à un individu. Ils sont reconnus et cela peut avoir un impact sur votre carrière professionnelle et tout le reste.

A dessiné: Pour les auditeurs qui ne sont peut-être pas habitués à Vue mais qui connaissent peut-être d'autres frameworks réactifs, tels que vous connaissez React, Angular, etc. Quels sont les grands changements de titre avec Vue 3 et quels problèmes essaient-ils de résoudre en particulier? Vous avez mentionné la composition tout à l'heure comme l'une de ces choses, est-ce l'un des grands changements?

Natalia: Oui, c’est l’un des changements les plus importants, et c’est en fait l’une des choses qui sont, avant tout, 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 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 insister sur ce point, c'est vraiment important de le dire, car quand il a annoncé pour la première fois l'API de composition, c'était un moment horrible.

Natalia: Je pense que nous n'avons pas vraiment bien décrit les changements et nous avons laissé entendre que la version standard sera l'API 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.

A dessiné: Dans quel genre de problème quelqu'un pourrait-il se retrouver là où l'API de composition est une nouveauté qui les aide à sortir de ce problème? Quel problème résout-il?

Natalia: Imaginez le composant qui a quelques fonctionnalités à 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 passé.

A dessiné: 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 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'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.

A dessiné: Cela semble vraiment aider les développeurs à nettoyer leurs bases de code en ce qui concerne des composants très complexes ou même une combinaison de composants légèrement complexe. Et vous avez mentionné la testabilité des mixins et autres, est-ce que l'API Composition permet une meilleure testabilité?

Natalia: Oui, certainement parce que Composition API, 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 à retourner.

A dessiné: Cela semble être une solution très complète à un problème que beaucoup de gens qui créent des applications plus complexes avec Vue apprécieront certainement. Et cela semble certainement être un très bon moyen d’éliminer le type de bogues qui, je le sais, 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.

A dessiné: 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 dans laquelle se trouver. Combien de temps vais-je perdre de sommeil 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 des alternatives à Vue 3. 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 qu’à l’heure actuelle, leur heure d’arrivée est en décembre si je me souviens bien, je devrais vérifier la feuille de route, mais je pense que nous sommes en 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.

A dessiné: L'outil de migration que vous avez mentionné semble donc assez intéressant. S'agit-il essentiellement d'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.

A dessiné: Avec l'état actuel de l'outil de migration, soyez 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 si cela semble correct ou s'il y a de grandes choses ou est-il encore immature pour cela? Vaut-il mieux attendre 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, maintenant 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 aussi un bon moyen pour nous car en jouant, vous découvrez des bogues, vous signalez des bogues, nous essayons de les corriger et ainsi de suite.

A dessiné: Dans la documentation et sur la feuille de route de développement, je vois la mention d'une construction 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 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 a créé un guide détaillé de ce qu'est le changement, pourquoi il a été fait et ce qui est en fait un remplacement ici.

A dessiné: Oui, dans la documentation se trouve un guide de migration assez complet dans le cadre de la documentation Vue 3 et il mentionne un grand nombre de changements qui doivent être migrés. 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, ça existe.

Natalia: Je dirais que les changements de modèle sont totalement révolutionnaires. 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 mérite vraiment votre attention.

A dessiné: 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 toujours le cas?

Natalia: Non, je pense que vous venez de trouver un bug, 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 consultez un doc-

A dessiné: Il y a une toute petite bannière en haut, oui.

Natalia: Oui, comme petit.

A dessiné: Ouais.

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'y a rien de contraste».

A dessiné: 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 le dirais. 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 six mois, un an, même pour des projets de grande envergure, il y aura migration.

A dessiné: Il me semble avoir dans ma carrière personnelle, un vrai talent pour venir sur les plateformes au moment même où elles sont 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 de sa migration, 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 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. Vous pouvez m'imaginer comme, 2018 et je rejoins GitLab. Je n’étais pas membre de l’équipe principale, je ne suis qu’un contributeur en ce moment.

Natalia: Immédiatement au même moment, Evan dit: «Oh, nous allons faire Vue 3». Tout le monde aime, "Ouais, cool". Printemps 2019, vous êtes le Core Teeam. Je veux dire que tout 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, tout le monde lira et votre propre entreprise se dit: "Oh, je veux apprendre quelque chose sur Vue 3, je ne peux pas comprendre vos documents." Alors vous vous dites: "Oh, putain, c'est tellement douloureux" parce que vous êtes développeur et rédacteur technique, un peu ici.

Natalia: Vous êtes au milieu de cela, mais je dois dire que c'est vraiment bénéfique pour le framework, car tout gros produit créé avec un framework est un excellent champ de bataille pour trouver des bogues et les ramener à la bibliothèque, à 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 de pointe 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.

A dessiné: En repensant à 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. Juste ce concept de prendre un sélecteur CSS et de l'utiliser pour interroger le DOM dans votre JavaScript était quelque chose que jQuery a popularisé. Et je pense que cela a vraiment résonné avec les développeurs assidus qui n'avaient pas besoin d'apprendre une nouvelle façon de travailler avec JavaScript. Je vois que Vue est presque le même genre de camp. J'ai mentionné que je travaillais auparavant avec React et que je suis passé à Vue au cours des dernières semaines, et j'ai trouvé que presque tout était plus intuitif dans le sens le plus authentique du terme, car je peux regarder quelque chose de inconnu et comprendre à peu près ce qu'il fait. Et si j'ai besoin de faire quelque chose que je n'ai pas fait avant, je peux en quelque sorte deviner comment cela serait mis en œuvre et généralement j'ai raison ou presque.

A dessiné: L'API de Vue est-elle quelque chose à laquelle l'équipe de base réfléchit de très près ou est-ce que cela s'est avéré presque comme un heureux accident à cause des personnalités impliquées?

Natalia: Je pense qu'à l'époque de Vue 2, nous avions un concept. Cela a légèrement changé, mais nous avions un concept appelé Conception pilotée par la documentation. Et c’est un concept vraiment génial, car si quelque chose est vraiment difficile à expliquer, vraiment difficile à obtenir et vraiment difficile à écrire, peut-être que l’API est erronée. Peut-être que quelque chose n'est pas développé comme il se doit parce que les solutions non intuitives, quelque chose qui est très cryptique, et que vous devez faire beaucoup de travail pour expliquer, ne sont généralement pas correctes. L'API a été conçue de la manière la plus simple à expliquer et c'est pourquoi elle est intuitive. Si c'est facile à expliquer, les gens comprendront probablement eux-mêmes. C’est pourquoi les anciennes directives telles que v-if et v-for semblent très familières à tout développeur JavaScript. Vous n'avez pas besoin d'expliquer ce que fait v-if parce que c'est clair, c'est vrai.

A dessiné: Ça l'est vraiment.

Natalia: C'est un peu insultant et c'est la même chose avec v-else. V-if, v-else-if, v-else et c'est tout. Et nous avons intuitivement construit v-for avec une syntaxe qui ressemble à une boucle for en JavaScript et de même pour la plus grande partie de l'API. Je pense que l'intention principale depuis Vue 1.x et je pense qu'Evan l'a également déclaré dans sa documentation était de créer quelque chose avec lequel vous aurez plaisir à travailler en tant qu'outil. Tout est aussi une question d’expérience des développeurs et je pense que c’est ce qui m’a également attiré dans Vue dans le passé. J'ai commencé avec Vue alors qu'il était déjà en version bêta pour la version 2. Je n'ai pas beaucoup travaillé avec Vue .1. Je pense que peu de gens connaissaient Vue depuis la première version, mais je me suis dit: "C'est tellement agréable à utiliser". Je construis juste les mêmes choses et c’est juste un plaisir. Je n'ai pas besoin de penser à l'outil, je pense à ce que je vais construire. Et l'outil ne m'empêche pas de faire ça.

Natalia: Et encore une fois, je dois dire que ce prochain sera une opinion totalement personnelle, pas en tant que membre de Vue Core Team. J'ai travaillé avec Angular de la version 2 à la version 6 sur un projet commercial et c'est un excellent framework. Il y a beaucoup de termes différents, il a beaucoup d'abstractions, l'injection de dépendances est incroyable, le support de TypeScript est absolument incroyable mais j'ai constamment eu l'impression de construire un mur avec d'énormes briques lourdes. Et je dois juste faire un effort pour déplacer chaque brique. Je veux dire, le mur est incroyable. Les briques sont encore lourdes et c’est difficile d’être développeur. Et après cela, travailler avec Vue, c'est comme: "Oh, c'est comme une promenade dans le parc".

A dessiné: Il peut y avoir un danger avec un logiciel que lorsqu'il est si bien conçu, il rend tout vraiment facile, qu'il soit en quelque sorte considéré comme un jouet, comme n'étant pas aussi puissant que les choses qui sont vraiment complexes. Pensez-vous que c'est un risque avec Vue, pensez-vous que cela pourrait être considéré comme moins sérieux que certains des autres frameworks réactifs simplement parce qu'il est mieux conçu?

Natalia: Oh, ça l'était. C'était pour cette raison et pour quelques autres raisons également. Et honnêtement, pendant un bon bout de temps, je pense que j'avais cette question, à chaque conférence à laquelle je m'étais adressé: «Recommanderiez-vous Vue pour un projet de grande taille, pour un projet d'entreprise, pour un projet aussi sérieux.» Et chaque fois que je me suis dit: «Oui, vous pouvez l'utiliser pour un petit projet, c'est facile d'échafauder quelque chose, vous pouvez l'utiliser pour le projet de grande taille et honnêtement, si nous parlons de projet de taille d'entreprise, le cadre est le moindre des les problèmes que vous devez résoudre.

Natalia: Vous pouvez prendre n'importe quel framework sur le marché, qu'il soit ancien, que ce soit Amber, que ce soit quoi que ce soit d'autre, que ce soit Angular One et créer une architecture bonne et stable. Vous pouvez prendre n'importe quel framework le plus récent, comme la dernière version Vue 3, Svelte, le dernier React et créer des éléments absolument incroyablement horribles. Cela dépend de la façon dont vous le construisez et de la façon dont votre équipe travaille dessus, de tout ce que vous avez là, de la façon dont vous avez planifié toutes les décisions architecturales car je pense qu'aucun cadre, peut-être un peu Angular, ne dicte une architecture. Un peu angulaire fait cette chose, les autres sont comme: «Vous êtes libre. Construit le." Et oui, aussi je pense que le problème avec Vue, pas un problème, mais le problème dans l’esprit des gens et en particulier dans l’esprit de la direction de l’entreprise, c’est qu’il n’est pas soutenu par une grande entreprise.

Natalia: Vous avez un Angular et Google se tient derrière Angular. Il y a React et Facebook qui soutient React. Il y a Vue et qui est le petit chinois, encore une fois, c'est comme une stigmatisation, il y a un cadre d'un gars, et si Evan You est heurté par un bus? Il y avait un article, «Et si Evan You est heurté par un bus», je jure sur dev.to. Je me dis: «Qu'est-ce qu'ils ont si peur?» Et les grandes entreprises sont probablement comme: «Et si elles abandonnent leur soutien, et si elles décident, peut-être même qu'il décide, si nous parlons d'Evan, et s'il décide qu'il ne veut pas travailler là-dessus. Et comme on peut le voir au fil des années, c'est bon et stable et ça se développe et ce n'est pas un problème et honnêtement, je pense que quand le framework est complètement open source et construit avec une équipe de personnes qui ne sont pas engagées, qui ne sont pas subjectives, qui ne le sont pas sous une seule grande entreprise, c'est mieux pour le cadre.

Natalia: L'année dernière, nous avons introduit le processus RFC. Il s’agit en fait d’une simple demande de commentaires. Nous avons une idée, nous la lâchons, les gens viennent là-bas et les gens se disputent là-bas et si nous créons un RFC pour quoi que ce soit, cela signifie que ce n’est pas décidé, ce n’est pas gravé dans le marbre. Nous avons juste une idée et nous voulons entendre ce que pense la communauté. Je pense que c'est génial car Vue est façonné par la communauté des développeurs. Ce ne sont pas que des mots forts. Non, ce n’est pas un slogan de production, par la communauté pour la communauté, je me souviens que nous l’avons utilisé mais c’est vrai. Il est en fait façonné par la communauté. Il n’est pas conçu pour les besoins d’une entreprise donnée. Même pour les grandes entreprises, même pour les entreprises qui parrainent Vue. Ils ne façonnent pas le cadre et je pense que c'est génial.

A dessiné: C’est assez révélateur lorsque vous avez mentionné que la liste des membres actifs de l’équipe principale est composée de 20 personnes et qu’elles sont toutes répertoriées sur le site et à côté de tout le monde, cela indique sur quoi vous travaillez dans le projet et où ils travaillent professionnellement. Et juste en regardant la liste des endroits où les gens travaillent professionnellement, je veux dire que vous êtes chez GitLab et il y a d'autres personnes qui ne sont que des consultants indépendants et ce n'est pas comme si 18 des 20 personnes travaillent chez Big Corp. Tout le monde contribue juste de partout. le lieu qui, comme vous le dites, est un véritable point de force.

Natalia: Ouais.

A dessiné: Qu'il n'y a pas un seul grand organisme qui le contrôle qui pourrait, pour ses propres besoins commerciaux, simplement dire: «Nous changeons de direction, nous n'allons plus faire cela» et retirer tout ce soutien et laisser le projet dans un désordre. Ce ne sont que de nombreuses personnes qui contribuent et font de leur mieux pour faire quelque chose de bien, ce qui, à mon avis, est une base très solide pour quelque chose d'aussi important qu'un cadre sur lequel les gens s'appuient.

A dessiné: Vous savez, j'ai passé la première moitié de cette année à apprendre React, puis à changer de travail et maintenant à apprendre Vue. Personnellement, cela me semble une bouffée d'air frais. Et je tiens vraiment à saluer le travail que vous et vos collègues faites à cet égard. Pour ceux qui souhaitent en savoir plus sur Vue, la version 3.0 ou tout simplement sur Vue, vous pouvez aller sur vuejs.org actuellement la version trois version spécifique comme nous l'avons mentionné est liée à la petite bannière en haut. Peut-être qu'au moment où vous écouterez ceci, le site aura changé et ne sera plus que Vue, mais c'est aussi là que vous trouverez la documentation et dans la documentation se trouve ce très bon guide de migration que nous avons mentionné. J’ai tout appris sur Vue 3.0, qu’avez-vous appris ces derniers temps, Natalia?

Natalia: J'ai appris la version 3 d'Apollo Client. C’est drôle, car si vous regardez les versions et que je les ai toutes les deux regardées, elles vont complètement de la même manière. Apollo Client était de 2,6 et Vue était de 2,6. Et Apollo a promis une libération pendant un an et ils l'ont retardée et retardée. C'était pendant longtemps en beta puis en release candidate. Il en était de même pour Vue, nous avons annoncé une version, puis nous l'avons retardée encore et encore et sommes passées à la version bêta un peu tard, puis nous sommes passées à la version candidate. Et ils ne sont pas sortis au même moment mais pas avec un grand décalage horaire. Apollo, je pense, est sorti en été, au début de l'été.

Natalia: Et nous utilisons également Apollo. Je l'utilise professionnellement et maintenant j'essaye en quelque sorte de construire quelque chose avec Vue 3 et Apollo 3, ce qui n'est pas une tâche facile car Apollo a fait un bon nombre de changements. Encore une fois, nous les ajustons au travail, mais, par exemple, supprimer les résolveurs locaux, c'est comme: «Que dois-je faire maintenant? Que dois-je faire avec mes requêtes locales? » Si vous êtes curieux de connaître la version 3 d'Apollo Client, essayez-le. Il est intéressant de voir comment cela évolue.

A dessiné: Je vais certainement essayer. J’ai utilisé Apollo sur quelques projets et c’est vraiment formidable de voir que cela progresse également. Si vous en tant qu'auditeur souhaitez en savoir plus sur Natalia, vous pouvez la suivre sur Twitter où elle est N_Tepluhina et vous pouvez trouver des collections de ses articles et vidéos de ses événements de prise de parole en public, dont une grande partie concerne Vue sur son site Web, nataliatepluhina .com

A dessiné: Merci de vous joindre à nous aujourd'hui, Natalia. Avez-vous des mots de départ pour nous?

Natalia: Pas vraiment, mais merci de m'avoir invité, c'était très amusant de parler là-bas.

Éditorial fracassant(il)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *