Cette fois, je vais vous apporter une explication pratique détaillée du projet Vue Family Bucket. Quelles sont les précautions pour utiliser Vue Family Bucket pour mettre en œuvre le projet. jetons un coup d'oeil.
D'un point de vue front-end, Vue peut être considéré comme le framework MVVM front-end le plus idéal à l'heure actuelle. Tout sert à l'interface, et il est facile de démarrer. Bucket de la famille Vue (Vue+Vue-router+Vuex) Le processus de reconstruction d'un projet jQuery+template et ce que j'ai gagné au cours du processus.
Démarrage
La documentation officielle de Vue est le meilleur tutoriel pour apprendre Vue. Probablement parce que l'auteur du framework est issu d'une formation en conception et n'a aucune expérience en back-end, divers concepts abstraits peuvent être expliqués de la manière la plus compréhensible dans Vue. présenter brièvement les concepts de Vue, Vue-router et Vuex Pour une étude complète, il est recommandé de se rendre à la documentation officielle.
Vue
La fonction principale de Vue est la liaison bidirectionnelle, qui peut réaliser automatiquement des modifications de données basées sur l'interface et des modifications d'interface basées sur les données, ce qui peut réduire considérablement le coût de développement d'applications interactives riches frontales. Il existe plusieurs frameworks similaires, Vue, mais l'implémentation de Vue présente certains avantages en termes de performances en tirant parti des fonctionnalités natives d'ES5.
Vue-routeur
Vue-router est la route officielle, utilisée pour organiser la relation de mappage entre les URL et les composants, et répondre automatiquement aux modifications des URL des composants, de sorte que les développeurs n'aient qu'à se concentrer sur le développement des composants, et le routage vous aidera à résoudre les problèmes associés. Des questions triviales.
Vuex
Vuex fournit un modèle de gestion de données centralisé pour gérer des situations de flux de données complexes. Par exemple, plusieurs composants partagent des données mais fonctionnent indépendamment, ce qui peut entraîner une désynchronisation des données synchronisées, ou en raison de Object object pointe vers la même instance dans la mémoire, provoquant la pollution d'autres composants une fois les données d'origine manipulées. À ce stade, un mode de fonctionnement des données plus organisé est nécessaire, qui est Vuex.
Sélection technique
Comparaison avec jQuery
Après avoir compris les concepts de base de Vue, je vais certainement les comparer inconsciemment avec la pile technologique jQuery, en me demandant si ces choses sont vraiment nécessaires pour mon entreprise. Tout d’abord, les problèmes résolus par MVVM peuvent-ils être résolus avec jQuery ? La réponse est oui. Vous souvenez-vous d'avoir utilisé jQuery pour obtenir les valeurs des entrées une par une lors de la soumission du formulaire ? Il s'agit de données basées sur l'interface ; si vous avez exécuté des fonctions interactives asynchrones, vous devez avoir de l'expérience dans l'utilisation de jQuery pour remplir des données Ajax dans divers éléments de l'interface. Bien que cela puisse être fait, c'est un peu fastidieux. Même si vous utilisez un plug-in de vérification de formulaire et un moteur de modèle frontal, vous devez toujours appeler manuellement la méthode de vérification et la méthode de rendu sur chaque nœud en cours d'exécution. créer une page de site Web, mais lorsque les exigences sont complexes dans une certaine mesure, cela constituera un gros fardeau. Ensuite, il y a le routage. L'essence du routage est de réaliser la commutation d'interface et la maintenance de l'interface en exploitant des URL. Cela n'a en fait rien à voir avec la pile technologique, même si les exigences de routage sont générées. les projets basés sur jQuery ne font que recréer un itinéraire. C'est tout, c'est juste que les applications d'une seule page sont rarement réalisées à l'ère de jQuery. Vuex est entièrement basé sur l'extension de la liaison bidirectionnelle, ce qui équivaut à ajouter un courtier entre les données et le composant. Le composant ne peut pas exploiter directement les données. Il ne peut que soumettre les exigences de fonctionnement au courtier, et le courtier les implémentera. l'opération.Pour résoudre divers problèmes imprévisibles causés par trop de personnes et trop de mains, et les données ont été déplacées hors de l'application, un magasin a été spécialement créé pour éliminer le problème de contamination des données entre les composants. Il faut dire que jQuery n'a pas cette exigence, car jQuery exploite entièrement les données manuellement et il n'y a aucune situation inattendue.Scénarios applicables
Après comparaison avec jQuery, les scénarios applicables de Vue sont évidents. Du point de vue du développement, les projets avec des interactions plus complexes sont plus adaptés, et les sites Web de contenu sont les moins adaptés s'il existe des besoins pour des pages individuelles dans le site Web. , ils peuvent également être partiels. Utilisez, par exemple, une page de panier. Bien sûr, tout cela doit être basé sur le principe qu'il n'est pas compatible avec IE8. Je suis un peu confus à ce sujet, car j'ai vu que certains sites 2C utilisent Vue. Comment ces front-end ont-ils trompé leurs patrons ?Analyse du projet
Contexte du projet
Le projet de refactoring est cette fois un système de gestion de composants frontaux développé pour une entreprise précédente. J'ai choisi de refactoriser ce projet car je connais les exigences. Il s'agit d'une application typique d'une seule page avec une complexité modérée et plus adaptée à son utilisation. comme un exercice pratique.
Le contexte du projet est que dans les entreprises de création de sites Web externalisées, un grand nombre de composants réutilisables sont accumulés dans le processus de conception. Les concepteurs n'ont souvent qu'à affiner les composants pour reconstituer la page et la livrer au front-end. En théorie, ces composants peuvent également être réutilisés dans le front-end, mais en fait dans le front-end, la page entière doit être réimplémentée à chaque fois, ce qui gaspille beaucoup de main-d'œuvre.
Exigences fonctionnelles
L'idée de ce projet est de développer tous les composants et de les saisir dans une plate-forme de gestion unifiée. Les concepteurs peuvent accéder à la plate-forme pour sélectionner les composants, puis prévisualiser et ajuster les composants en temps réel. Obtenez pendant tout le processus, et la plateforme générera un résultat d'ajustement. Tant que le code est transmis au front-end, vous pouvez utiliser cette chaîne de code pour reproduire le composant modifié par le concepteur sur la plateforme. copiez également le code html/css/js du composant en un clic et appliquez-le rapidement au projet. Le coût de développement front-end pour la partie composant est proche de zéro. La plateforme doit mettre en œuvre les fonctions suivantes :
Gérer les composants, prendre en charge la classification, la recherche, le tri
Afficher les composants, prendre en charge l'aperçu/l'édition en ligne des composants
Transfert des composants, prendre en charge la génération de composants coder et reproduire les statistiques d'utilisation des composants
Analyse fonctionnelle
La première version a été implémentée à l'aide de jQuery+template. Cette pile technologique est trop flexible. L'avantage est qu'il est facile de faire tout ce qui est nécessaire. L'inconvénient est que cela peut être fait quoi qu'il arrive. s'accompagne souvent de changements en le faisant.
Les composants sont uniformément placés dans un dossier widgets/, appelé bibliothèque de composants. Puisqu'il s'agit d'un pur projet frontal sans capacités d'exploitation de fichiers, la lecture des composants repose sur un fichier json statique. Ce fichier sert de répertoire. bibliothèque de composants, qui comprend des composants pour toutes les informations telles que les catégories, les balises, les noms, les dates, etc., la structure des données ressemble à ceci :
[{
"title": "导航类",
"list": [{
"widget": "bread-1",
"title": "图标面包屑",
"tag": "面包屑/图标",
"author": "UI",
"date": "2015-06-04"
},
...]
},
...]Les composants sont stockés dans la bibliothèque de composants sous la forme de dossiers secondaires en colonnes/numéros, et il est convenu d'utiliser le répertoire de stockage comme code du composant. Par exemple, le composant bread-1 signifie que l'adresse de stockage du composant est widgets/bread/. 1/ dossier.
Bien entendu, la structure des fichiers internes du composant doit également être convenue, comme suit :
widgets |-bread |-1 |-album.jpg //缩略图 |-config.json //配置文件 |-script.js //脚本模板 |-style.css //样式模板 `-temp.htm //界面模板
Avec ces conventions, le programme peut obtenir les informations de tous les composants via des fichiers de répertoire, et l'acquisition, l'affichage et la récupération des composants peuvent également être réalisés.
L'élément le plus critique du composant est le fichier config.json, qui contient les éléments configurables du composant et ses valeurs par défaut. La plateforme lira ce fichier de configuration lors de l'affichage du composant et générera un panneau de configuration basé sur les informations de configuration. vous pouvez Définir toutes les variables dans le composant interface, style et script. Le fichier de configuration peut ressembler à ceci :
{
"cssConfig": {
"fontSize": {
"name": "字号",
"value": "12px",
"type": "text"
},
...
},
"jsConfig": {
...
},
"showConfig": {
"viewWidth": {
"name": "栅格宽度",
"value": 12,
"type": "number"
},
...
}
}. Les trois branches de cssConfig, showConfig et jsConfig dans le fichier de configuration sont l'ensemble de toutes les variables qui peuvent être modifiées dans le composant. Si vous souhaitez appliquer ces variables au composant, vous devez utiliser le moteur de modèle frontal, Ainsi, les trois composants principaux du composant sont développés à l'aide de la syntaxe du modèle et, après analyse par le moteur de modèle, le contenu html/css/js réellement configuré peut être obtenu. Par exemple, le modèle de style ressemble à ceci :
.widget-bread-1 {
font-size: ${fontSize.value};
color: ${textColor.value};
}
.widget-bread-1 a {
color: ${textColor.value};
}
.widget-bread-1 a:hover{
color:${hoverColor.value};
}
.widget-bread-1 .ion {
font-size: ${iconSize.value};
margin: 0 ${iconMargin.value};
}du composant, afin que d'éventuels conflits de noms CSS puissent être résolus de manière invisible.
Ce qui précède sont les fonctions principales du projet.De plus, localStorage est utilisé comme méthode de stockage pour implémenter des statistiques de données pour la version autonome. Il peut collecter les enregistrements d'utilisation des composants du navigateur actuel et la configuration de chaque utilisation. Il s'agit principalement du fonctionnement du stockage local, mais c'est le cas. également utilisé pour le développement du projet lui-même. En ce qui concerne les modèles frontaux, ainsi que les modèles de composants, ils seront mis en cache à l'aide de localStorage après le premier chargement. Les stratégies de mise en cache pour ces contenus doivent être stockées de manière permanente. les modèles de projet doivent être mis à jour manuellement et les modèles de composants doivent être déterminés en fonction de la situation. S'il y a trop de contenu stocké, il est irréaliste de les supprimer un par un pendant le nettoyage. endommager accidentellement le stockage d'autres applications. La méthode ici consiste à encapsuler l'opération localStorage, et la méthode de stockage sera ajoutée avant la clé. Lors de la suppression d'un préfixe spécial, il vous suffit de parcourir la clé stockée localement et de déterminer si elle correspond à la clé. préfixe pour savoir s'il est stocké dans l'application. La méthode de récupération de valeur correspondante doit également ajouter le préfixe à la clé à l'envers puis récupérer la valeur.
De plus, localStorage ne prend en charge que l'accès aux chaînes.Afin de faciliter notre accès aux types d'objets, la méthode d'encapsulation prend également en charge la conversion automatique. Cependant, cette conversion ne peut pas convertir aveuglément les caractères lorsque la valeur correspond. vers un objet. L'objet est automatiquement transféré, car parfois l'utilisateur peut réellement enregistrer une chaîne d'objet et vouloir la récupérer telle quelle lors de sa suppression. Pour résoudre ce problème, vous devez faire un petit hack lors de la méthode de stockage. détecte que la valeur est un objet, , sera convertie en chaîne puis précédée d'une chaîne d'identification. La méthode value ne restituera la chaîne suivante à un objet qu'après avoir détecté cette identification. Bien que cette méthode puisse répondre aux besoins, elle l'est. pas très sûr. Parce que ce préfixe est fixe, il est toujours possible de rencontrer un gagnant à la loterie en théorie. Je ne sais pas s'il existe d'autres meilleures solutions à ce problème.
Ce sont les principaux points fonctionnels du projet.
Refactor
Une reconstruction
La première refactorisation utilisait uniquement Vue. La première chose que j'ai réalisée au cours du processus de refactorisation était les diverses commodités. Ce que je voulais à l'origine appeler le moteur de modèle était fait par le framework pour lequel je voulais à l'origine lier des événements en js, mais maintenant je l'ai fait. peut le faire directement dans le modèle Bindings et divers autres sucres syntaxiques.
Bien sûr, la chose la plus importante est la liaison bidirectionnelle. Basée sur la liaison bidirectionnelle, l'interface et les données peuvent être automatiquement associées, ce qui donne aux utilisateurs le sentiment que le programme dispose d'un certain degré d'autonomie. fonctionner normalement, les développeurs doivent planifier à l'avance. Chaque étape du processus apparaîtra moins gratuite que jQuery. Prenons l'exemple du déplacement de briques. JQuery est comme une grue particulièrement flexible qui peut facilement soulever des briques et les déplacer de manière sophistiquée ; Vue est comme une télécommande universelle. Vous lui dites que vous souhaitez déplacer des briques d'un certain endroit vers. un certain endroit. Ce qui se passe pendant le processus dépend de la façon de le gérer, les briques peuvent être déplacées automatiquement en appuyant sur le bouton.
Les deux méthodes ont leurs propres avantages et inconvénients. Si la grue est bien conduite, elle peut être très flexible et il est facile d'éviter les creux sur la route. L'inconvénient est que vous devez la conduire encore et encore ; être programmé pour fonctionner automatiquement en même temps, mais l'inconvénient est que vous devez définir la position sur la route à l'avance. Effectuer des inspections sur place, planifier toutes les autres voitures et expliquer clairement toutes les situations, sinon la voiture se renversera ou s'écrasera. En passant de jQuery à Vue, vous ressentirez certainement ce sentiment de retenue, vous obligeant à « planifier avant d'agir ». Vous ne pouvez pas en parler avant de monter dans la voiture.
Une grande partie du travail pendant la période de reconstruction consiste à établir des instances Vue, à collecter des données dispersées dans tous les coins de js en données, à concentrer le processus d'exploitation des données petit à petit dans des méthodes et à concentrer le processus de filtrage des données dans les calculs. processus, vous pouvez clairement examiner chaque détail de mise en œuvre et réfléchir à la question de savoir si chaque méthode de mise en œuvre est raisonnable. En fait, il s'agit de résumer le processus original de conduite d'une grue en boutons de télécommande un par un. Lorsque tout le résumé est terminé, la Vue. exemple Cela devient notre projet final qui peut s'exécuter automatiquement.
Après reconstruction, le recours à diverses fonctions de Vue a réduit la quantité de code dans la partie logique. En dehors de cela, il n'y a aucune amélioration pour le projet lui-même. Car il n'y a pas de routage, le problème de la perte du statut de la page d'actualisation persiste. existe ; parce que Vuex n'est pas utilisé, si vous rencontrez un gouffre de pollution des données, vous ne pouvez utiliser que la copie profonde pour le résoudre et le modèle de développement basé sur les composants rend l'organisation du code plus fragmentée.
Deuxième reconstruction
L'objectif de la deuxième reconstruction est d'améliorer le routage, Vuex, l'organisation du code et le backend Dingo Cloud.
Bien que j'aie l'expérience du premier refactoring, je suis encore un peu confus au début du deuxième refactoring. Lequel faut-il implémenter en premier, le routage ou Vuex ? Après y avoir réfléchi, ce que fait le routage, c'est "démonter", et ce que fait Vuex, c'est "modifier". Je pense que la charge de travail de démontage après modification sera plus petite, j'utilise donc d'abord Vuex.
Le concept de Vuex est un peu abstrait à comprendre à partir de rien, mais une fois que vous l'utilisez, vous vous sentez très à l'aise. De plus, contrairement au routage, il peut être utilisé sans distinguer de scénarios. Après l'introduction de Vuex, le problème de la pollution des données. est naturellement résolu, et Vuex apporte action => mutation => Une fois le processus accepté, les choses deviendront vraiment plus simples. Le processus d'introduction de Vuex consiste essentiellement à transférer les données vers le magasin et à disperser les opérations de données en actions, getters et mutations. En même temps, de nombreuses opérations de données synchrones ne sont plus. nécessaire, rendant ainsi le code Le montant a été un peu réduit.
Après cela, j'ai commencé à introduire le routage. Au début, je ne savais pas comment diviser les vues. Les grandes vues doivent être la connexion, l'enregistrement et l'interface principale. En théorie, c'est le cas. peut être divisé très finement, mais sur la base des scénarios d'utilisation réels de l'application, il a été constaté que le changement d'interface est relativement fréquent et que le chargement et le déchargement fréquents des composants coûteront cher. De plus, la division des composants étroitement couplés en différentes vues nécessite l'enregistrement de nombreuses informations d'état. , ce qui n'en vaut pas la peine. Au final, nous avons abandonné et n'avons pas changé la vue principale. Étant donné que le chevauchement d'accès des trois vues n'est pas élevé, il est naturel de charger le composant de manière asynchrone et de charger le composant uniquement lorsqu'il est accédé. Vue elle-même prend en charge les composants asynchrones, cela devient donc très simple, tant qu'il le peut. retournez une promesse, vous pouvez obtenir des composants de n'importe quelle manière.
Ensuite, nous devons accéder au Wild Dog Cloud pour obtenir une véritable gestion des utilisateurs et des statistiques de données. Le Wild Dog Cloud peut fournir une série de fonctions telles que l'authentification des utilisateurs et le stockage des données. Grâce à lui, une application WEB complète peut être développée en utilisant uniquement js. . De cette façon, toutes les opérations précédentes sur localStorage doivent être remplacées par des opérations sur Wild Dog Cloud, et les données deviennent plus fiables lorsqu'elles atteignent le cloud.
À ce stade, la deuxième refactorisation est terminée. Le code métier global semble considérablement réduit, mais le volume total de code n'est pas beaucoup moins important. Après tout, trois fichiers de framework ont été ajoutés. de fichiers a été supprimé des trois ou deux fichiers js d'origine. Il est devenu une douzaine de js, et seajs est utilisé à la place du webpack pour la modularisation, car personnellement, je n'aime pas. Webpack a toujours une attitude attentiste, et je ne ressens pas encore le besoin de l'utiliser. La clé est que le code développé sur la base de webpack sera mélangé à de nombreux éléments privés, ce qui rendra votre code non natif. et impossible de fonctionner sans cela. Je ne pense pas. C'est tellement acceptable, et dans les scénarios multipages, seajs a plus d'avantages que webpack lorsqu'il est combiné avec la mise en cache locale. Bien sûr, leur différence est la même que celle entre jQuery. et Vue. Ce n'est pas la même chose en substance. La clé réside dans le scénario d'utilisation. Celui qui convient est le meilleur.
Post-scriptum
Après deux pratiques de refactorisation et pièges, j'ai une compréhension plus approfondie du framework Vue. Si Vue doit être utilisée de manière flexible et libre, il existe une exigence minimale pour les capacités d'architecture de projet des développeurs. Si Vue doit être introduite dans la couche inférieure, les bases Il existe également une exigence minimale pour les capacités de planification des constructeurs d'installations, qui n'existent pas dans la pile technologique jQuery. Le processus d'utilisation de Vue est également un processus d'acceptation de ces contraintes. Elles peuvent guider les développeurs pour établir leurs propres systèmes de règles. C’est une bonne chose et c’est la tendance générale. Après tout, la vraie liberté n’existe que dans le cadre de règles.
Je pense que vous maîtrisez la méthode après avoir lu le cas dans cet article. Pour des informations plus intéressantes, veuillez prêter attention aux autres articles connexes sur le site Web chinois de php !
Lecture recommandée :
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
Comment fonctionne le capteur de température
La différence entre vscode et vs
tutoriel d'exécution de code c++
Annuler la campagne WeChat
Comment gérer les téléchargements de fichiers bloqués dans Windows 10
utilisation des balises de jeu de champs
Comment afficher le HTML au centre
Comment sauter avec des paramètres dans vue.js
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
