Fermer

octobre 24, 2019

10 bonnes pratiques pour la construction de grands projets Vue.js


Voici les meilleures pratiques que j'ai développées lorsque je travaillais sur des projets Vue dotés d'une base de code volumineuse. Ces conseils vous aideront à développer un code plus efficace, plus facile à gérer et à partager.

Lors de la mise en freelance de cette année, j’ai eu l’occasion de travailler sur de grandes applications Vue. Je parle de projets comportant plus d'une douzaine de magasins Vuex, un nombre élevé de composants (parfois des centaines) et de nombreuses vues (pages). Ce fut en fait une expérience enrichissante pour moi car j'ai découvert de nombreux modèles intéressants pour rendre le code évolutif. J'ai également dû corriger certaines mauvaises pratiques qui ont abouti au fameux dilemme du code spaghetti. 1965

Ainsi, aujourd’hui, je vous fais part de 10 meilleures pratiques que je vous recommanderais de suivre si vous avez affaire à une base de codes volumineuse. ??‍♀️

1. Utiliser les emplacements pour rendre vos composants plus faciles à comprendre et plus puissants

J'ai récemment écrit un article sur sur certaines choses importantes que vous devez savoir sur les emplacements dans Vue.js . Il explique comment les emplacements peuvent rendre vos composants plus réutilisables et plus faciles à gérer et pourquoi vous devez les utiliser.

Mais qu'est-ce que cela a à voir avec les grands projets Vue.js? Une image vaut généralement mille mots, alors je vais vous décrire la première fois que je regrettais profondément de ne pas l'avoir utilisée.

Un jour, je devais simplement créer une fenêtre contextuelle. Rien de très complexe à première vue car il ne s'agissait que d'un titre, d'une description et de boutons. Donc, ce que j'ai fait était de tout passer comme des accessoires. Je me suis retrouvé avec trois accessoires que vous utiliseriez pour personnaliser les composants et un événement a été émis lorsque des personnes ont cliqué sur les boutons. Peasy facile! ?

Mais au fur et à mesure que le projet prenait de l'ampleur, l'équipe nous a demandé d'afficher de nombreuses autres nouveautés: champs de formulaire, boutons différents selon la page sur laquelle il était affiché, des cartes, un pied de page et la liste. continue. Je me suis dit que si j'utilisais des accessoires pour faire évoluer ce composant, tout irait bien. Mais mon dieu, je me suis trompé! Le composant est rapidement devenu trop complexe à comprendre car il comprenait d'innombrables composants enfants, utilisait beaucoup trop d'accessoires et émettait un grand nombre d'événements. Je suis arrivé à vivre cette terrible situation dans laquelle, lorsque vous effectuez un changement quelque part et que vous finissez par casser quelque chose d'autre sur une autre page. J'avais construit un monstre Frankenstein au lieu d'un composant maintenable! 1965

Cependant, les choses auraient pu être mieux si j'avais compté sur les créneaux horaires dès le début. J'ai fini par refacturer tout pour arriver à ce petit composant. Plus facile à maintenir, plus rapide à comprendre et bien plus extensible!

  

Mon point de vue est que, par expérience, les projets conçus par des développeurs qui savent quand utiliser les créneaux horaires ont une grande incidence sur leur maintenabilité future. Beaucoup moins d’événements sont émis, le code est plus facile à comprendre et offre beaucoup plus de flexibilité car vous pouvez afficher tous les composants que vous souhaitez à l’intérieur.

En règle générale, n’oubliez pas que lorsque vous finissez par dupliquer votre Les accessoires des composants enfants dans leur composant parent, vous devriez commencer à utiliser les emplacements à ce stade.

2. Organisez correctement votre magasin Vuex

Généralement, les nouveaux développeurs de Vue.js commencent à en apprendre davantage sur Vuex car ils sont tombés par hasard sur l'une de ces deux questions:

  • Ils ont besoin que les données persistent après la destruction du composant
  • C'est à ce moment-là qu'ils créent leur premier magasin Vuex, découvrent les modules et commencent à les organiser dans leur application. ?

    En réalité, il n'y a pas de modèle à suivre lors de la création de modules. Cependant, je vous recommande vivement de réfléchir à la manière dont vous souhaitez les organiser. D'après ce que j'ai vu, la plupart des développeurs préfèrent les organiser par fonctionnalité. Par exemple:

    • Auth.
    • Blog.
    • Boîte de réception.
    • Paramètres.

    De mon côté, il est plus facile de comprendre quand ils sont organisés en fonction des modèles de données qu'ils extraient du API. Par exemple:

    • Utilisateurs
    • Equipes
    • Messages
    • Widgets
    • Articles

    Lequel vous choisissez est à vous. La seule chose à garder à l'esprit est qu'un magasin Vuex bien organisé donnera une équipe plus productive à long terme. Cela incitera également les nouveaux venus à mieux comprendre votre code de base lorsqu'ils rejoindront votre équipe.

    3. Utiliser des actions pour effectuer des appels d'API et valider des données

    La plupart de mes appels d'API (si ce n'est tous) sont effectués dans le cadre de mes actions Vuex. Vous pouvez vous demander: pourquoi est-ce un bon endroit pour le faire?

    ??‍♀️ Tout simplement parce que la plupart d'entre eux récupèrent les données que je dois valider dans mon magasin. En outre, ils fournissent un niveau d'encapsulation et de capacité de réutilisation avec lequel je suis vraiment ravi de travailler. Voici d'autres raisons pour lesquelles je le fais:

    •     

      Si je dois récupérer la première page d'articles à deux endroits différents (disons le blog et la page d'accueil), je peux simplement appeler le répartiteur approprié avec les paramètres appropriés. Les données seront récupérées, validées et renvoyées sans autre code que le call du dispatcheur.

          

    •     

      Si j'ai besoin de créer une logique pour éviter d'extraire cette première page lorsqu'elle a déjà été extraite, je peux le faire à un endroit. En plus de réduire la charge sur mon serveur, je suis également convaincu que cela fonctionnera partout.

          

    •     

      Je peux suivre la plupart de mes événements Mixpanel dans le cadre de ces actions, ce qui rend la base de code analytique très facile à gérer. J'ai quelques applications où tous les appels Mixpanel sont faits uniquement dans les actions. Je ne peux pas vous dire à quel point c'est une joie de travailler de cette façon lorsque je n'ai pas à comprendre ce qui est suivi à partir de ce qui ne l'est pas et à quel moment ils ont été envoyés.

    4. Simplifiez votre base de code avec mapState, mapGetters, mapMutations et mapActions

    Il n'est généralement pas nécessaire de créer plusieurs propriétés ou méthodes calculées lorsque vous devez simplement accéder à vos états / getters ou appeler vos actions / mutations au sein de vos composants. À l'aide de mapState mapGetters mapMutations et mapActions peuvent vous aider à raccourcir votre code et à rendre les choses plus faciles à comprendre en regroupant ce qui vient. vos modules de magasin au même endroit.

     // NPM
    importer {mapState, mapGetters, mapActions, mapMutations} de "vuex";
    
    défaut d'exportation {
      calculé: {
        // Accès aux propriétés de la racine
        ... mapState ("mon_module", ["property"]),
        // Accéder aux getters
        ... mapGetters ("mon_module", ["property"]),
        // Accès aux propriétés non root
        ... mapState ("mon_module", {
          propriété: state => state.object.nested.property
        })
      },
    
      méthodes: {
        // Accéder aux actions
        ... mapActions ("mon_module", ["myAction"]),
        // Accéder aux mutations
        ... mapMutations ("mon_module", ["myMutation"])
      }
    };
    

    Toutes les informations dont vous avez besoin sur ces aides pratiques sont disponibles ici dans la documentation officielle de Vuex .

    5. Utiliser les usines API

    J'aime généralement créer un assistant this. $ api que je peux appeler n'importe où pour récupérer mes points de terminaison API. À la base de mon projet, j'ai un dossier api qui inclut toutes mes classes (voir l'une d'entre elles ci-dessous).

     api
    ├── auth.js
    ├── notifications.js
    └── teams.js
    

    Chacune d'elles regroupe toutes les extrémités de sa catégorie. Voici comment initialiser ce modèle avec un plugin dans mes applications Nuxt (il s'agit d'un processus assez similaire dans une application Vue standard):

     // PROJECT: API
    importer Auth de "@ / api / auth";
    importer des équipes de "@ / api / teams";
    importer des notifications depuis "@ / api / notifications";
    
    export default (context, inject) => {
      if (process.client) {
        const token = localStorage.getItem ("jeton");
        // Set token une fois défini
        si (jeton) {
          contexte. $ axios.setToken (jeton, "porteur");
        }
      }
      // Initialiser les référentiels d'API
      référentiels const = {
        auth: Auth (contexte. $ axios),
        équipes: équipes (contexte. $ axios),
        notifications: Notifications (contexte. $ axios)
      };
      injecter ("api", référentiels);
    };
    
     export default $ axios => ({
      MotPasse oublié (email) {
        return $ axios. $ post ("/ auth / password / oublié", {email});
      },
    
      login (email, mot de passe) {
        return $ axios. $ post ("/ auth / login", {email, mot de passe});
      },
    
      se déconnecter() {
        return $ axios. $ get ("/ auth / logout");
      },
    
      enregistrer (charge utile) {
        return $ axios. $ post ("/ auth / register", charge utile);
      }
    });
    

    Je peux simplement les appeler dans mes composants ou actions Vuex comme ceci:

     export default {
      méthodes: {
        onSubmit () {
          essayer {
            this. $ api.auth.login (this.email, this.password);
          } catch (error) {
            console.error (erreur);
          }
        }
      }
    };
    

    6. Utilisez $ config pour accéder aux variables d’environnement (particulièrement utile dans les modèles)

    Votre projet contient probablement des variables de configuration globale définies dans certains fichiers:

     config
    ├── development.json
    └── production.json
    

    J'aime y accéder rapidement via un assistant this. $ Config surtout lorsque je suis dans un modèle. Comme toujours, il est assez facile d’étendre l’objet Vue:

     // NPM
    importer Vue de "vue";
    
    // PROJET: COMMUNES
    importer le développement de "@ / config / development.json";
    importer la production de "@ / config / production.json";
    
    if (process.env.NODE_ENV === "production") {
      Vue.prototype. $ Config = Object.freeze (production);
    } autre {
      Vue.prototype. $ Config = Object.freeze (développement);
    }
    

    7. Suivez une seule convention pour nommer vos commissions

    À mesure que le projet avance, vous devrez parcourir l'historique des composants régulièrement. Si votre équipe ne suit pas la même convention pour nommer ses commits, cela rendra plus difficile la compréhension de ce que chacun fait.

    J'utilise toujours et recommande les instructions de message de validation angulaire . Je le suis dans tous les projets sur lesquels je travaille, et dans bien des cas, les autres membres de l'équipe s'aperçoivent qu'il est préférable de le suivre également.

    Le respect de ces consignes donne lieu à des messages plus lisibles qui permettent de suivre plus facilement les commits lorsque historique du projet. En résumé, voici comment cela fonctionne:

     git commit -am " (): "
    
    # Voici quelques exemples
    git commit -am "docs (changelog): met à jour le changelog vers beta.5"
    git commit -am "correctif (version): besoin de dépendre des dernières versions de rxjs et de zone.js"
    

    Consultez leur fichier README pour en savoir plus à ce sujet et sur ses conventions .

    8. Toujours figer les versions de vos packages lorsque votre projet est en production

    Je sais … Tous les packages doivent suivre les règles de versioning sémantiques . Mais la réalité est que certains ne le font pas. ?

    Pour éviter de vous réveiller au milieu de la nuit car l'une de vos dépendances a cassé votre projet dans son intégralité, verrouillez toutes vos versions de package pour rendre votre journée de travail moins stressante. ?

    Cela signifie simplement ceci: évitez les versions précédées de ^ :

     {
      "nom": "mon projet",
    
      "version": "1.0.0",
    
      "privé": vrai,
    
      "dépendances": {
        "axios": "0.19.0",
        "imagemin-mozjpeg": "8.0.0",
        "imagemin-pngquant": "8.0.0",
        "imagemin-svgo": "7.0.0",
        "nuxt": "2.8.1",
      },
    
      "devDependencies": {
        "préfixe automatique": "9.6.1",
        "babel-eslint": "10.0.2",
        "eslint": "6.1.0",
        "eslint-friendly-formter": "4.0.1",
        "eslint-loader": "2.2.1",
        "eslint-plugin-vue": "5.2.3"
      }
    }
    

    Lorsque vous avez besoin d'afficher un grand nombre de lignes dans une page donnée ou lorsque vous avez besoin de parcourir en boucle une grande quantité de données, vous avez peut-être remarqué que le rendu de la page peut devenir assez lent. Pour résoudre ce problème, vous pouvez utiliser vue-virtual-scoller .

     npm installer vue-virtual-scroller
    

    Cela rendra uniquement les éléments visibles de votre liste et réutilisera les composants et les éléments dom pour être aussi efficace et performant que possible. C'est vraiment facile à utiliser et fonctionne comme un charme! ✨

    
    

    10. Suivi de la taille de vos packages tiers

    Lorsque plusieurs personnes travaillent dans le même projet, le nombre de packages installés peut rapidement devenir incroyablement élevé si personne ne leur prête attention. Pour éviter que votre application ne soit ralentie (en particulier sur les réseaux mobiles lents), j'utilise le package de coûts d'importation dans Visual Studio Code. De cette façon, je peux voir directement dans mon éditeur quelle est la taille d’une bibliothèque de modules importée et vérifier ce qui ne va pas quand elle devient trop grande.

    Par exemple, dans un projet récent, toute la bibliothèque lodash a été importée ( environ 24kB gzippé). Le problème? Seule la méthode cloneDeep a été utilisée. En identifiant ce problème avec le package de coût d'importation, nous l'avons corrigé avec:

     npm remove lodash
    npm installer lodash.clonedeep
    

    La fonction clonedeep peut ensuite être importée si nécessaire:

     import cloneDeep de "lodash.clonedeep";
    

    ⚠️ Pour optimiser encore les choses, vous pouvez également utiliser le package Webpack Bundle Analyzer pour visualiser la taille de vos fichiers de sortie Webpack avec un treemap zoomable interactif.


    Existe-t-il d'autres meilleures pratiques traiter avec une grande base de code Vue? N'hésitez pas à me le signaler dans les commentaires ci-dessous ou à me contacter sur Twitter @RifkiNada .







    Source link