Écrire devant
Récemment, je suis tombé sur du chargement de contenu dans l'emballage modulaire angulaire au travail. J'ai senti que j'avais des pièges au milieu, alors je l'ai marqué ici.
Contexte du projet:
Le projet utilise principalement AngularJS comme cadre frontal. Lorsque le projet a été publié auparavant, tous les scripts frontaux seraient emballés et compressés dans un fichier. Il sera chargé lorsque la page sera accessible pour la première fois, ce qui entraîne un chargement initial lent de la page. Sur cette base, il est proposé de charger à la demande, c'est-à-dire que les scripts du module ne seront chargés que lorsque l'utilisateur accède à un certain module.
Outils:
Le projet utilise des emballages de grognement selon les spécifications AMD, utilise un grogn-contribe-requirejs pour comprimer et fusionner les modules, et utilise Oclazyload pour compléter le chargement paresseux du module angulaire.
Processus du projet:
Emballage du module
Le code du projet est essentiellement écrit conformément à la spécification AMD, et Grunt-Contrib-Requirejs est utilisé pour compresser chaque module dans un fichier JS.
Question 1: Dans le code du projet, chaque module s'appuiera sur des bibliothèques tierces / services publics dans le projet / instructions publiques du projet. Si cette partie du contenu n'est pas traitée, Grunt-Contrib-Requirejs chargera tous les modules dont il dépend lors de la compression de chaque module, puis le comprimez dans le même fichier JS.
Réponse: Compressez la bibliothèque tierce / services publics et les instructions en trois modules, puis supprimez-le en utilisant "exclure" du script d'emballage de chaque module. Comme indiqué dans la figure ci-dessous:
Il convient de noter que le nom du module du module public doit avoir un fichier JS avec le même nom sous le chemin d'accès correspondant.
Charge à la demande
Après l'emballage du script en fichiers js par module, l'étape suivante consiste à charger différents modules en fonction des demandes de l'utilisateur. Le projet utilise l'interface utilisateur pour gérer les sauts de routage. Vous pouvez commencer à partir de l'itinéraire pour terminer le chargement paresseux des modules.
La méthode spécifique est la suivante: lorsque l'utilisateur exploite le saut d'itinéraire, le module auquel l'utilisateur appartient est chargé en fonction de l'état que l'utilisateur souhaite sauter. Sur la base de cela, une cartographie entre l'état et le module doit être ajoutée. Au début, il est nécessaire de le charger avec requirejs. On constate que le script peut être chargé, mais les contrôleurs / services / filtres enregistrés en Angular ne fonctionnent pas. L'enquête a révélé que des services tels que les contrôleurs enregistrés par Angular après avoir appelé la méthode bootstrap ne seront plus appelés. Sur la base de cela, Oclazyload est introduit au chargement (Oclazyload a une certaine injection et modifications au code source angulaire).
Jusqu'à présent, le chargement à la demande a été essentiellement mis en œuvre, mais il y a encore plusieurs problèmes:
Dépendances du projet entre les modules
Étant donné qu'il existe de fortes dépendances entre les projets entre certains modules, le traitement consiste à ajouter des dépendances entre les modules dans le fichier de configuration. Avant de charger un module, vérifiez s'il a un module dépendant. Si c'est le cas, le module dépendant sera chargé en premier. Une fois le module dépendant chargé, le module actuel sera chargé.
Chargement paresseux des instructions;
Dans Angular, $ compile peut être utilisé pour implémenter l'interdépendance entre les instructions. Le traitement est de configurer le nom d'instruction et la dépendance du module d'instruction. Lorsqu'une certaine instruction est utilisée, le module est chargé en premier, puis la méthode de compilation est exécutée. Cette solution peut résoudre la plupart des dépendances des instructions.
L'emplacement des instructions. La plupart des projets utilisent des pages longues, chaque longue page est divisée en plusieurs domaines et chaque zone est une commande. Il y aura un problème lors de l'utilisation d'interception, c'est-à-dire que le temps de chargement de chaque instruction est différent. Les commandes qui reviennent en premier seront d'abord ajoutées au DOM, ce qui entraîne une incertitude dans la mise en page de la page. La solution consiste à utiliser le mécanisme deffer et, après toutes les instructions, les instructions sont chargées / compilées, ajouter une exécution à l'arborescence DOM.
Dépendances entre les directives: il existe également des dépendances de projet entre les directives. La solution à cela consiste à fusionner les instructions interdépendantes dans un module et à les emballer dans le même fichier de script. Cette solution peut résoudre la plupart des dépendances de l'instruction, mais ne peut pas résoudre les dépendances pendant le processus d'initialisation. Il peut y avoir une certaine instruction compilée et les dépendances sur l'instruction n'ont pas encore été compilées. Pour un exemple aussi super spécial, seul le script et le modèle sont chargés lorsque la page est initialisée.
Ce qui précède sont les problèmes rencontrés tout au long du processus de projet. Fondamentalement, chaque fois que vous avancez, vous marchez sur une fosse. Beaucoup de choses sont la première fois que vous entrez en contact avec eux, et je pense que j'ai appris quelque chose. Les solutions à de nombreux problèmes peuvent ne pas être très claires. D'autres ont rencontré tous les problèmes ci-dessus. Tant que vous utilisez bien le moteur de recherche et lisez / comprenez vous-même le code des autres, tous les problèmes peuvent être résolus avec succès.
Certains pièges sur le chargement paresseux angulaire sont tout le contenu que je partage avec vous. J'espère que vous pourrez vous faire référence et j'espère que vous pourrez soutenir Wulin.com plus.