Consommation mémoire angulaire2 d'un très grand SPA - application mémoire, angulaire, à une seule page

Nous sommes en train de concevoir un nouveau site Webdemande d’utilisation interne d’une entreprise et le système frontal sera créé dans MVC 6 et Angular2. Le projet est assez vaste ... l'analyse montre environ 1000 formulaires. De plus, chaque terminal aura accès à une quantité de mémoire finie (nous ne savons pas encore exactement combien), car nous servirons les pages via Citrix.

Je comprends que Angular2 est créé avec de grandes applications en tête, mais j’identifie certains problèmes concernant un aussi grand SPA:

1. Objet de déclaration de module principal trop volumineux. 1000 formulaires dans l'analyse des besoins représentent le double de ce nombre dans les composants seuls, un moyen de minimiser cela?
2. Combien de mémoire Angular2 réserve-t-il aux fichiers chargés?Composants? Vérification de la mémoire du tas JS. Je peux voir qu’il réserve les prototypes de composants dans Heap, jusqu’à acheminement vers une autre page. Je ne peux trouver aucune information sur la gestion de la mémoire de Ang2, donc tout lien ou information serait plus que bienvenu!
3. Existe-t-il une quantité optimale de composants par module? Une suggestion est de diviser le SPA en plusieurs plus petits, chacun dans sa propre vue MVC.

Ma principale préoccupation est le problème n ° 2. La quantité de mémoire finie est un problème sur un projet avec autant de composants. Le client souhaite un "onglet dynamique, comme une application", dans lequel il a accès à n’importe quelle vue à tout moment et puisse en garder plus d’une. Le fractionnement de l'application en plusieurs vues MVC rendra cette fonctionnalité difficile à implémenter.

tl; dr: Besoin d'informations et de directives sur la consommation de mémoire angulaire 2 de très grands SPA!

Merci beaucoup d'avance!

Réponses:

Je ne vois pas de problème avec le nombre de formulaires. Les composants sont juste compilés en JavaScript et ne prendront pas beaucoup de mémoire.

Lorsque les composants sont instanciés, ils occupent un espace supplémentaire pour les variables membres qui conservent son état et un état géré par Angular.

Ce qui cause généralement des problèmes, c’est quand un énormenombre de composants sont affichés en même temps (même en dehors de la zone visible - au lieu d’afficher tout ce qui est nécessaire, comme le défilement virtuel), car cela prend beaucoup de temps de calcul et peut ralentir le navigateur et le rendre inactif.

La taille des modules en elle-même n’a aucune importance.
Des modules ont été introduits pour prendre en charge le chargement paresseux de parties de l'application en combinaison avec le routeur.
Par conséquent, mettez des parties de votre application en paresseuxmodules chargés qui ne sont pas nécessaires au chargement initial. Vous pouvez charger des parties de l'application (modules chargés paresseux) à la demande lorsque l'utilisateur navigue vers un itinéraire spécifique.