Amélioration de l'application Vue.js. Quelques conseils pratiques
Dominik Grzedzielski
Senior Software Engineer
Vue est un framework progressif à croissance rapide pour la construction d'interfaces utilisateur. Il est devenu le framework JavaScript avec le plus d'étoiles sur GitHub et le projet le plus étoilé de 2016 et 2017 sur le même portail.
Créer des applications en Vue est vraiment simple en soi, mais si vous voulez créer des applications de bonne qualité, vous devrez relever un défi un peu plus grand.
Faire partie de The Codestéquipe et véritable défenseur de la Technologie VueJe souhaite partager avec vous quelques conseils (non copié à partir de la documentation officielle du Vue) qui améliorera sans effort code la qualité et la performance des applications Vue.
Tout d'abord, appliquez le guide de style Vue et ESLint
Vous y trouverez quatre catégories de règles. Trois d'entre elles nous intéressent particulièrement :
Essentiel des règles qui nous empêchent de commettre des erreurs,
Recommandé et fortement recommandé règles pour conserver les meilleures pratiques - à améliorer la qualité et la lisibilité du code.
Vous vous dites peut-être... "Quoi ? Dois-je me souvenir de toutes les règles ?" Bien sûr que non. Vous pouvez utiliser ESLint pour s'occuper de ces règles à votre place. Il vous suffit de tout paramétrer correctement dans le fichier de configuration d'ESLint. Je suggère d'utiliser l'option recommandé préétabli vous obtenez un ensemble de règles totalement gratuites qui vous aident à construire des applications avec de bonnes pratiques. Comment l'installer ?
Par défaut, vous devriez trouver s'étend dans la configuration d'ESLint et remplacer "plugin:vue/essentiel" avec "plugin:vue/recommended"c'est tout.
Bien sûr, il y a quelques règles à respecter, car ESLint ne peut pas tout gérer tout seul. Par exemple :
une dénomination cohérente,
la dénomination des événements dans la boîte à kebab,
préfixation $_namespace_ propriétés privées dans les plugins, mixins, etc,
ordre des éléments de premier niveau d'un composant de fichier unique.
Ne pas utiliser plusieurs v-if
Il peut parfois être nécessaire de rendre conditionnellement plus d'un élément, mais les gens écrivent souvent quelque chose comme cela :
contenu
contenu
contenu
Ce n'est pas nécessaire parce que nous pouvons l'écrire plus élégamment :
Mais qu'en est-il si nous voulons le faire en tant qu'élément racine ? Dans le cas d'un Vuenous ne pouvons pas utiliser <template> à cette fin. Dans certains cas, il suffit de l'envelopper dans du papier d'emballage.
C'est bien, mais, même si nous le voulons, nous ne pouvons parfois pas envelopper les éléments dans des div, par exemple, à cause de la sémantique html (par exemple. doit être un enfant direct de
ou ). Ainsi, lorsque nous devons écrire :
(( item.name ))
...et nous verrons une erreur comme celle-ci :
Nous pouvons y remédier en en utilisant JSX et un composant fonctionnelOn peut aussi passer un booléen qui remplacera le v-if.
</>
Ne pas écrire les gestionnaires d'appels d'api dans les composants
En fait, ce n'est qu'un des exemples de ce qu'il ne faut pas faire dans les composants. Il suffit de faire ce qui est localement nécessaire dans la logique des composants. Toute méthode qui pourrait être externe devrait être séparée et appelée uniquement dans les composants, par exemple la logique métier.
Utiliser des créneaux plutôt que de grandes quantités d'accessoires
Parfois, l'utilisation d'accessoires est suffisante, mais il y a aussi des cas où ils ne sont pas efficaces. Cela peut se produire dans des situations où nous devrions ajouter trop d'accessoires pour que le composant fonctionne comme nous le souhaitons. L'exemple le plus simple est celui d'un bouton. Il s'agit sans aucun doute d'un composant qui peut être utilisé n'importe où dans une application. Considérons donc un composant de type bouton comme celui-ci.
(( texte ))
A ce stade, il s'agit d'un simple composant qui n'accepte que du texte. Ok, mais ce n'est peut-être pas suffisant car nous aurons besoin d'icônes dans le bouton. Dans ce cas, nous devons ajouter 2 autres accessoires (2, parce que nous voulons avoir l'option d'ajouter avant ou après le texte). Ainsi, le composant ressemblera à ceci :
(( texte ))
Ce n'est pas mal, nous n'avons que 3 accessoires, mais...
Et si nous avions besoin d'un indicateur de chargement ? Eh bien, nous devrions ajouter un autre accessoire. Et ce, pour chaque nouvelle fonctionnalité ! Suivre l'augmentation du nombre de composants vous semble-t-il un défi aujourd'hui ? Oui, sans aucun doute !
Utilisons plutôt des créneaux.
Plus simple, non ? Ok, mais comment pouvons-nous obtenir la fonction d'ajout d'icône ? C'est très simple ! Il suffit d'utiliser le composant comme ceci :
Retour
Suivant
Un moyen simple d'améliorer les performances
Je vais partager avec vous quelques conseils qui sont vraiment faciles à mettre en œuvre, afin que vous puissiez en bénéficier immédiatement.
Itinéraires de chargement paresseux
Parfois, nous avons des routes qui ne sont disponibles que pour les administrateurs, ou les utilisateurs ayant un accès particulier, elles peuvent également être moins visitées que d'autres. Ce sont des cas parfaits pour l'utilisation de la route lazy load.
Il suffit d'utiliser la fonction arrow dans la propriété de votre composant pour renvoyer la fonction d'importation :
Grâce au chargement paresseux de ce composant, il ne sera téléchargé que lorsqu'il sera demandé. Par exemple, si nous avons un composant avec v-if, il ne sera demandé que si le composant doit être rendu. Ainsi, si la valeur v-if n'est pas vraie, le composant ne sera pas chargé. C'est pourquoi l'importation paresseuse peut également être utilisée pour les composants de type JavaScript dossiers.
Bonus : Lorsque l'on utilise Vue CLI 3+, toutes les ressources chargées paresseusement sont préfixées par défaut !
Utiliser des enveloppes transparentes au lieu d'attributs accessoires
Prenons l'exemple d'un composant comme celui-ci :
Sans aucun problème, nous pouvons l'utiliser comme suit :
ou
Cela fonctionne, car Vue vous permet de transmettre des attributs html au composant, même si vous ne les avez pas déclarés en tant qu'accessoires. Les attributs html sont appliqués à l'élément racine du composant (input, dans ce cas).
Le problème apparaît lorsque nous voulons développer notre composant d'entrée, car il pourrait ressembler à ceci :
Maintenant, en utilisant le composant de cette façon :
ne fonctionnera pas comme nous le souhaitons, car le type et l'espace réservé seront appliqués à div (l'élément racine) et cela n'a aucun sens. Nous devons donc nous en occuper, car nous voulons ajouter nos attributs à l'élément input. Votre première pensée peut être "ajoutons les accessoires dont nous avons besoin !" et bien sûr cela fonctionnera, mais... que se passe-t-il si nous voulons utiliser type, autocomplétion, espace réservé, autofocus, handicapé, mode d'entréeetc., nous devons alors définir les props pour chaque attribut html. Personnellement, je n'aime pas cette longue méthode, alors cherchons quelque chose de mieux !
Nous pouvons traiter l'ensemble du problème en seulement deux lignes.
Nous pouvons utiliser v-bind= "$attrs" et transmettre les attributs directement à <input> sans déclarer d'énormes quantités d'accessoires. N'oubliez pas non plus d'ajouter l'option inheritAttrs : false afin de ne pas transmettre les attributs à l'élément racine. Allons un peu plus loin : que se passe-t-il si nous avons besoin d'ajouter des récepteurs d'événements à cette entrée ? Encore une fois, cela pourrait être géré par des accessoires ou des événements personnalisés, mais il y a une meilleure solution.
Il existe une nouvelle propriété calculée qui renvoie le composant pour les auditeurs et ajoute l'auditeur d'entrée. Nous utilisons cette entrée calculée en écrivant simplement v-on="listeners".
Utiliser l'observateur avec l'option immediate au lieu du crochet créé et de l'observateur ensemble
Nous récupérons souvent des données sur un crochet créé (ou monté), mais nous devons ensuite récupérer ces données à chaque modification d'une propriété, par exemple la page en cours de la pagination. Certains ont tendance à l'écrire comme ceci :
Bien sûr, cela fonctionne, mais... Ce n'est pas la meilleure approche, ni même une bonne. Alors, voyons comment nous pouvons refactoriser cela, un exemple d'une approche pas si mauvaise :
La version ci-dessus est meilleure parce qu'une autre méthode n'est pas nécessaire, nous avons seulement nommé une méthode qui doit être appelée pour modifier watchProperty.
Nous nous sommes débarrassés du crochet de création. En ajoutant l'option "immediate", nous faisons en sorte que ce composant appelle la méthode fetchData immédiatement après le début de l'observation (un peu avant le crochet created et après beforeCreated), de sorte qu'il peut être utilisé à la place du crochet created.
Résumé des conseils de Vue.js
Ces conseils ne rendront pas votre candidature parfaite, mais leur mise en œuvre permettra d'accélérer le processus. améliorer la qualité de votre code. J'espère également que vous trouverez quelque chose d'intéressant dans les exemples ci-dessus.
Notez que certaines d'entre elles ont été simplifiées pour les besoins de l'article.