Tricky, Tricky – Conseils de migration cachés pour Vue 3

Dans ce billet de blog, nous explorerons quelques astuces de migration délicates qui vous aideront à adopter en douceur Vue 3.

«J'adore le processus de migration vers une version plus récente de notre logiciel» – n'a jamais déclaré aucun développeur.

Dans ma carrière jusqu'à présent, j'ai effectué plusieurs dizaines de migrations, même si je savais que la migration ressemble souvent à ceci:

et travaille actuellement sur migration build mais une ressource de plus est toujours utile, j'ai donc décidé de décrire plusieurs changements peu connus sur lesquels je suis tombé par hasard lors de la migration des composants Kendo UI for Vue .

J'ai choisi les cas les plus délicats pour moi: émettant des événements avec des noms natifs utilisant les fonctions de rendu et mixins merges . Chacun de ces rares cas pourrait vous aider à saisir un bug qui pourrait facilement être manqué lors du processus de migration. Dans mon prochain blog, je partagerai également toutes les étapes à suivre pour ra commune «Application de mise en route» lors de la mise à niveau de notre application « Kendo Vue – Mise en route » de Kendo UI Template Wizard .

Emission d'événements avec des noms natifs

I utilisent souvent un dossier avec des composants en couche mince autour d'un bouton, d'une entrée ou même d'un div et que je l'utilise dans mon application – j'appelle ceux-ci mes petites armes. Le petit piège ici est que j'ai tendance à émettre des événements qui ont les mêmes noms que le composant natif, de sorte que je puisse facilement basculer entre eux. Comme dans le code ci-dessous:

 < button   @  click  =  "onClick"  > One click </  button > [19659018] < MyButton   @  click  =  "onClick" > Two Clicks </  MyButton > 

Dans Vue 3, ayant cette configuration déclenchera l'événement deux fois comme vous pouvez le voir dans cet exemple modifiable .

Une façon possible de résoudre ce problème est d'utiliser la toute nouvelle option Vue 3 'emits' comme il est décrit dans la documentation ici ou empêchez simplement l'événement natif en le déclarant comme 'nul' qui ne déclenchera que l'événement personnalisé.

 émet: {  
    click:  null    
  },   
   ... 

Utilisation des fonctions de rendu

Vous vous souvenez de mes petites armes? Eh bien, les fonctions de rendu, par contre, sont comme des bazookas. Ils offrent une grande flexibilité et doivent être manipulés avec soin. Vue 3 apporte un énorme changement dans la syntaxe, et la structure entière des accessoires VNode est aplatie. Tout changement dans de tels scénarios doit être traité avec un soin particulier car ils pourraient facilement nous écraser avec une pierre:

 // 2.x 

 {  
   [19659031] staticClass:  'button'    
    class: {   
    'est délimité' : isOutlined    
   },    
    staticStyle: {   
    couleur:  '# 34495E'    
   },    
    style: {   
    backgroundCouleur:    
    buttonColor    
   },    
    attrs: {id:  'submit'  },    
    domProps: {innerHTML:  ''   },    
    sur: {click: submitForm},    
   [19659031] clé:  'submit-button'    
  } 
            

 // 3.x Syntax 

 {  
    classe: [   
    'button' {   
    'is-outline' : isOutlined    
   }    
  ]  
    style: [   
    {couleur:  '# 34495E'  },    
    {   
   backgroundColor: buttonColor   
  }   
    ]   
    id:  'submit'    
    innerHTML:  ''    
    onClick: submitForm,    
    clé:  'submit-button'    
  } 
            

Another la chose délicate ici est la partie où nous utilisons une fonction de rendu avec encore un autre composant. Dans ce cas, nous devons définir les enfants comme la fonction cela apporte plus de performances car les accessoires ne seront enregistrés qu'en tant que dépendance des composants enfants:

 // slow 
 h (Comp, 
 {
 // props / attributes 
}, 
 // tableau d'enfants 
 this. $ Slots.default () 

 // fast   [19659005]   h (Comp,   
   {  
   // accessoires / attributs   
  },   
   () => [  
   [19659127] this . $ Slots.  default  ()    
  ]) 

Exemple de code – https://stackblitz.com/edit/yyyupr-pzu5ny

Mixins Merges

Au tout début de Vue 2, les mixins étaient vraiment à la mode et pouvaient être facilement utilisés pour toutes sortes de fins de structure d'application. Vue 3 change la donne pour eux grâce à l'introduction de l'API de composition . Même si certaines fonctionnalités de mixins sont toujours prises en charge, je recommanderais vraiment de reconsidérer leur utilisation et de ne plus les utiliser.

Un scénario où les choses peuvent casser est mélanger des fusions de données . Cela peut conduire nous à un autre «rocher» lorsque, dans le composant résultant, les options de données fusionnées pourraient être attendues – mais n'existeront plus.

 // code mixin   
   const Mixin = {  
    données () {   
    return   {   
    utilisateur: {   
    nom: [19659014] «Jack»    
    id: 1,    
   },    
   };    
   },    
  }; 
            

 export  default   {  
    name:  "HelloWorld"    
    mixins: [Mixin]   
   [19659031] données () {   
    retour   {   
    utilisateur: {   
    id: 2,    
   [19659145]},    
   };    
   },    
  }; 
            

Dans de tels cas, la documentation officielle de Vue recommande soit:

• Extraction des données partagées dans un objet externe et en l'utilisant comme propriété dans les données, ou
• Réécriture des références aux données partagées pour pointer vers un nouvel objet partagé (tel qu'il est décrit ici ).

J'aime beaucoup comment la fonction de configuration déclare tous les paramètres, voici donc ma première option pour résoudre ce problème avec le code:

 // code baseuser   
   export  par défaut   {  
    utilisateur: {   
    nom:  "Jack"    
    id: 1    
   }    
  }; 
            

  

   setup () {  
    const data = reactive ({   
    utilisateur: {   
    id: 2,    
    ... baseuser.user,    
   },    
   });    
    return   data; 
            

Exemple ici: https://codesandbox.io/s/immutable-hill-twofr[19459009[19659007[LessonsLearned)

J'ai passé plusieurs semaines à migrer toutes les Kendo UI pour les composants Vue vers Vue 3, et encore plus pour migrer environ 1000 exemples! Même si j'ai lu attentivement tous les guides de changement et de migration, je me sentais encore souvent comme ceci:

@ pa4oZdravkov

Bon codage et bonne migration!