Composer une grande application Angular 2 avec plusieurs petites applications dans
Après 3 mois de débats et de recherches sur le choix entre React (avec Redux) et Angular 2, l'équipe front-end de mon entreprise a conclu de choisir Angular 2 (étant donné que cela est plus adapté à notre problème).
Nous sommes dans le domaine des applications d'entreprise, qui comprend actuellement de nombreuses technologies frontales différentes (tout en ayant RESTful complet), et nous voulions tout remplacer et disposer d'une technologie unique pour faciliter la formation future et le contrôle de la qualité.
Compte tenu de la nature de notre produit, il est vaste et contient des modules, qui sont en soi un domaine différent et peuvent être créés en tant qu'application autonome, mais le produit lui-même vit dans une seule URL.
Exemple;
Appelons mon produit SuperApp.
En tant qu'interface utilisateur, SuperApp dispose d'un système de connexion standard et d'une navigation vers les modules/sous-produits enfants, de sorte que le flux de travail s'affiche comme suit.
SuperApp
- Authentifier l'utilisateur
- Assistant Oublier le mot de passe
- Page publique accessible sans authentification
Utilisateur authentifié
Système de navigation
- Accueil
- Sous-produit1
- Sous-produit2
- Sous-produit3
Profil
...
...
Groupes
...
...
- Accueil
Notez que dans la représentation ci-dessus, Sub-product1 Et Sub-product2 Sont deux domaines entièrement différents, ayant des domaines commerciaux entièrement différents.
Ce que je peux penser en ce moment, c'est que je peux créer SuperApp comme un seul projet Angular 2 ayant uniquement des composants et des vues qui sont pertinents pour lui-même, et SuperApp est également responsable du chargement de plusieurs applications enfants; Sub-product1, Sub-product2 (Encore une fois, différents Angular 2 projets, ayant leur propre package.json, webpack config, etc.) via des composants muets et agissez comme un shell qui fournit un routage de niveau supérieur et un espace réservé pour contenir ces applications enfants.
Une fois que Sub-product1 Est chargé dans le Shell, il ajoutera ses propres routes à la route actuelle sur laquelle SuperApp a atterri.
La raison pour laquelle je veux la séparation est parce que ces différentes applications (qui sont actuellement construites en utilisant ExtJS) ont des équipes dédiées qui y travaillent (nous sommes une entreprise ayant plus de 500 développeurs), donc si elles ont leurs propres projets Angular, elles peut gérer ses outils et ses dépendances à sa guise sans se fier à l'application grand-parent.
Mais je ne peux trouver nulle part dans les documents officiels Angular ou sur le Web que la possibilité d'avoir des applications Angular imbriquées est possible (de telle sorte que le code cadre est partagé alors que les dépendances des applications enfants sont complètement isolés et chargés uniquement lorsque l'application en a besoin), ou s'il existe une autre approche pour résoudre un tel problème.
Tout conseil ou même des liens vers des articles pertinents seront appréciés.
Une option: vous pouvez "lier en dur" (au lieu d'utiliser des liens SPA) aux sous-applications et faire en sorte que chaque sous-application partage une dépendance pour l'encapsuleur de site.
Ce que vous décrivez, je le sais par le module therm. Je vais donc faire référence à est en tant que tel.
Je ne vais pas répondre à la question de savoir si angular modules de support pour manque de connaissances sur le cadre. De plus, à mon avis, vous ne voulez pas vraiment cela. À ma connaissance, et je m'attends à ce que votre backend reflète, vous voulez tout couper dans les plus petits bits que vous pouvez (micro services).
Dans ce cas, chaque point de votre diagramme doit être sa propre application indépendante. Ils doivent bien sûr communiquer entre eux, en fonction de chaque responsabilité de composer la vue que vous avez décrite. Vous avez vu comment Google a une URL/un outil/un système séparé pour authentifier? Gmail ne se soucie pas de cela car ce n'est pas de sa responsabilité. Même le skining de tous les outils est central au lieu d'être situé dans chaque outil (vous le voyez sur la conception des matériaux). Les actifs vivent en dehors de chaque projet/système.
Vous obtenez ainsi un levier plus élevé de réutilisabilité et de flexibilité de vos systèmes. Bien que dans les petites équipes, cela est intenable en raison de la complexité et du temps. Maintenant, c'est à vous de déterminer où se situe votre dossier. Tous dans les micro services et la séparation, le tout dans un seul paquet ou quelque part au milieu. Et les modules, s'ils sont disponibles, sont quelque chose que vous utiliseriez à l'intérieur de chaque point.