À mesure que la demande augmente, les fonctions du projet deviennent plus complexes. À ce stade, il faut modulariser les composants du projet et les packages, instructions et pipelines en blocs fonctionnels cohérents, ce qui est parfait pour explorer les sous-routes et le chargement paresseux des modules dans Angular4.
Dans le développement précédent, une fonction de routage simple a été implémentée dans le module racine, qui peut être résumée en trois étapes suivantes :
1、在app.module.ts文件中加载路由库，并且在@NgModule中引入RouterModule.forRoot方法，其中，appRoutes是路由数组，它定义了具体的路由规则。
2. Ajouter une barre de navigation au composant shell, où la commande routerLink pointe vers la destination de la route, et routerLinkActive ajoute le style css à l’etiquetage sélectionnée
3. Ajouter une commande router-outlet au modèle du composant shell, et la vue s’y affichera
Maintenant, je veux mettre en place des sous-routes et un chargement paresseux des modules sur cette base.
RouterModule.forRoot() et RouterModule.forChild()
L’objet RouterModule fournit deux méthodes statiques : forRoot() et forChild() pour configurer les informations de routage.
La méthode RouterModule.forRoot() est utilisée pour définir l’information de routage principale dans le module principal, et RouterModule.forChild() est similaire à la méthode Router.forRoot(), mais ne peut être appliquée que dans les modules de fonctionnalités.
C’est-à-dire que forRoot() est utilisé dans le module racine et forChild() est utilisé dans le sous-module.
Son fils Lu Ru
Supposons qu’il y ait deux pages sous nos pages de paramètres /settings, /settings/profile et /settings/password, qui représentent respectivement la page de profil et la page de changement de mot de passe. définissant comme un bloc de fonctions distinct, qui peut être encapsulé dans un module de fonctionnalités. Il dispose de ses propres routes indépendantes, et les routes pour les pages de profil et de mot de passe peuvent être définies comme des sous-routes.
Dans le module SettingsModule, nous utilisons la méthode forChild(), car SettingsModule n’est pas le module principal de notre application.
Une autre différence majeure est que nous définissons le chemin principal du module SettingsModule sur un chemin vide (''). Parce que si on met le chemin sur /settings, il correspond à /settings/settings. En spécifiant un chemin vide, cela correspond au chemin /settings.
Chargement paresseux : loadChildren
Configurez les informations de routage du module de réglage dans le module racine AppModule :
La propriété LoadChildren à chargement paresseux est utilisée ici. Au lieu d’importer le module Settings dans l’AppModule, la propriété loadChildren indique à la route Angular de charger le module SettingsModule selon le chemin configuré par la propriété loadChildren. C’est l’application spécifique de la fonction de chargement paresseux du module : lorsque l’utilisateur accède au chemin /settings/**, le module SettingsModule correspondant sera chargé, ce qui réduit la taille de la ressource chargée au démarrage de l’application.
La valeur des biens de loadChildren se compose de trois parties :
Des chemins relatifs pour importer des modules sont nécessaires
#分隔符
Exportez le nom de la classe de module
Module CommonModule
J’ai mentionné que je voulais introduire le module CommonModule dans le module feature, mais je n’avais pas remarqué que je voulais l’introduire dans le module feature au début, et en conséquence, l’erreur de page a été signalée lors du routage :
core.es5.js:1020 ERROR Error: Uncaught (in promise): Error: Template parse errors:
Impossible de lier à 'ngClass' car ce n’est pas une propriété connue de 'div'.
Impossible de lier à 'ngForOf' car ce n’est pas une propriété connue de 'p'.
La liaison de propriété ngForOf n’est utilisée par aucune directive sur un modèle intégré. Assurez-vous que le nom du bien est correctement orthographié et que toutes les directives sont listées dans les « @NgModule.déclarations ».
Impossible de lier à 'ngIf' car ce n’est pas une propriété connue de 'div'.
......
Après avoir vérifié longtemps, j’ai découvert que c’était parce que je n’avais pas introduit CommonModule dans le module de fonctionnalités, et qu’après l’avoir introduit, ces erreurs disparaissaient.
CommonModule fournit de nombreuses instructions couramment utilisées dans les applications, y compris NgIf et NgFor. Plus précisément, des directives telles que NgIf sont déclarées dans le CommonModule depuis @angular/common.
Nous avons importé le module BrowserModule dans le module racine AppModule, qui a importé le CommonModule et l’a réexporté. Le résultat final est que tant que vous importez le BrowserModule, vous recevrez automatiquement les instructions dans le CommonModule.
L’importation d’un BrowserModule rend tous les composants, directives et pipelines exposés par le module accessibles directement dans n’importe quel modèle de composant sous l’AppModule, sans étapes supplémentaires et fastidieuses. Mais n’importe pas le BrowserModule dans un autre module. Les modules de fonctionnalités et les modules de chargement paresseux devraient être importés dans CommonModule à la place. Ils ne nécessitent pas de réinitialiser le fournisseur complet au niveau de l’application. Si vous importez un BrowserModule dans un module de chargement paresseux, Angular affiche une erreur.
Voici quelques-uns des problèmes et résumés que j’ai rencontrés ces deux derniers jours avec des sous-routes Angular et un chargement paresseux.
|
Publié sur 13/06/2019 13:13:10
|
|
|
|
