Implémentation d’un framework de plugin architecture / plugin system / pluggable dans Angular 2, 4, 5, 6

Mise à jour 24/05/2018: Nous sums maintenant des versions +3 d’Angular depuis mon message initial et nous n’avons toujours pas de solution définitive. Lars Meijdam (@LarsMeijdam) a mis au point une approche intéressante qui vaut certainement le détour. (En raison de problèmes de propriété, il a dû supprimer temporairement le référentiel GitHub où il avait initialement posté son échantillon. Cependant, vous pouvez lui envoyer un message directement si vous souhaitez en obtenir une copie. Veuillez consulter les commentaires ci-dessous pour plus d’informations.)

Les modifications architecturales récentes apscopes à Angular 6 nous rapprochent d’une solution. De plus, les éléments angulars ( https://angular.io/guide/elements ) fournissent des fonctionnalités de composant – mais pas tout à fait ce que j’ai décrit à l’origine dans cet article.

Si quelqu’un de l’incroyable équipe Angular arrive à trouver cela, veuillez noter qu’il semble y avoir beaucoup d’autres personnes qui sont également très intéressées par cette fonctionnalité. Il pourrait bien être intéressant de considérer l’arriéré.

Je voudrais implémenter un framework enfichable (plug-in) dans une application Angular 2 , Angular 4 , Angular 5 ou Angular 6 .

(Mon cas particulier de développement de ce framework enfichable est que je dois développer un système de gestion de contenu miniature. Pour un certain nombre de raisons qui ne sont pas nécessairement développées ici, Angular 2/4/5/6 convient parfaitement à la plupart des besoins. de ce système.)

Par framework enfichable (ou architecture de plug-in), j’entends spécifiquement un système qui permet aux développeurs tiers de créer ou d’étendre les fonctionnalités d’une application principale via l’utilisation de composants enfichables sans avoir directement access au code source de l’application principale. ou fonctionnement interne .

(Cette formulation sur ” sans avoir directement access au code source de l’application ou à son fonctionnement ” est un objective essentiel).

Des exemples de frameworks enfichables incluent des systèmes de gestion de contenu communs tels que WordPress ou Drupal .

La situation idéale (comme avec Drupal) serait de pouvoir placer ces composants enfichables (ou plug-ins) dans un dossier, de faire en sorte que l’application les détecte automatiquement ou les découvre, et les fait “fonctionner” comme par magie. Cela se produirait d’une manière hot-plug, c’est-à-dire que l’application était en cours d’exécution, serait optimale.

J’essaie actuellement de déterminer ( avec votre aide ) les réponses aux cinq questions suivantes.

1. Praticité: Un framework de plugin pour une application Angular 2/4/5/6 même pratique? (Jusqu’à présent, je n’ai trouvé aucun moyen pratique de créer un cadre réellement connectable avec Angular2/4/5/6 .)
2. Défis attendus: Quels défis pourrait-on rencontrer en implémentant un framework de plugin pour une application Angular 2/4/5/6 ?
3. Stratégies de mise en œuvre: Quelles techniques ou stratégies spécifiques pourraient être utilisées pour implémenter un framework de plug-in pour une application Angular 2/4/5/6 ?
4. Meilleures pratiques: Quelles sont les meilleures pratiques pour implémenter un système de plug-in pour une application Angular 2/4/5/6 ?
5. Technologies alternatives: Si un framework de plugin n’est pas pratique dans une application Angular 2/4/5/6 , quelles technologies relativement équivalentes (par exemple, React ) pourraient convenir à une application Web hautement réactive moderne ?

En général, l’utilisation de l’ Angular 2/4/5/6 est très souhaitable car:

• il est naturellement extrêmement rapide – de manière éclatante.
• il consum très peu de bande passante (après le chargement initial)
• son encombrement est relativement faible (après le tree shaking et tree shaking ) – et cette empreinte continue de diminuer
• il est très fonctionnel et l’équipe Angular et la communauté continuent de croître rapidement de son écosystème
• il joue bien avec la plupart des technologies Web les meilleures et les plus récentes telles que TypeScript et Observables
• Angular 5 prend désormais en charge les travailleurs des services ( https://medium.com/@webmaxru/a-new-angular-service-worker-creating-automatic-progressive-web-apps-part-1-theory-37d7d7647cc7 )
• étant soutenu par Google , il sera probablement pris en charge et amélioré dans le futur

J’aimerais beaucoup utiliser Angular 2/4/5/6 pour mon projet actuel. Si je peux utiliser Angular 2/4/5/6 , j’utiliserai également Angular-CLI et probablement Angular Universal (pour le rendu côté serveur).

Voici mes pensées, jusqu’ici, concernant les questions ci-dessus. S’il vous plaît examiner et fournir vos commentaires et éclaircissements.

• Angular 2/4/5/6 applications Angular 2/4/5/6 consumnt des packages – mais ce n’est pas nécessairement la même chose que d’autoriser des plug-ins au sein d’une application. Un plugin dans d’autres systèmes (par exemple Drupal ) peut être ajouté en déposant le dossier du plugin dans un répertoire commun des modules où il est automatiquement “capté” par le système. Dans Angular 2/4/5/6 , un package (en tant que plug-in) est généralement installé via npm , ajouté à package.json , puis importé manuellement dans l’application – comme dans app.module . Ceci est beaucoup plus compliqué que la méthode Drupal pour supprimer un dossier et pour que le système détecte automatiquement le paquet. Plus il est compliqué d’installer un plugin, moins les gens seront susceptibles de les utiliser. Ce serait bien mieux si Angular 2/4/5/6 détecter et installer automatiquement les plugins. Je suis très intéressé de trouver une méthode qui permet aux non-développeurs d’installer l’application Angular 2/4/5/6 et d’installer les plugins choisis sans avoir à comprendre toute l’architecture de l’application.

• En général, l’un des avantages de fournir une architecture enfichable est qu’il est très facile pour les développeurs tiers d’étendre les fonctionnalités du système. De toute évidence, ces développeurs ne seront pas familiarisés avec toutes les subtilités du code pour l’application à laquelle ils se connectent. Une fois les plugins développés, d’autres utilisateurs encore moins techniques peuvent simplement installer l’application et tous les plugins sélectionnés. Cependant, Angular 2/4/5/6 est relativement compliqué et a une courbe d’apprentissage très longue. Pour compliquer encore les choses, la plupart des applications Angular 2/4/5/6 production utilisent également des Angular-CLI , Angular Universal et WebPack . Quelqu’un qui met en œuvre un plug-in devrait probablement avoir au moins quelques connaissances de base sur la manière dont tous ces éléments s’emboîtent – ainsi qu’une solide connaissance pratique de TypeScript et une connaissance raisonnable de NodeJS . Les besoins en connaissances sont-ils si extrêmes qu’aucun tiers ne voudrait jamais développer un plug-in?

• La plupart des plugins auront probablement un composant côté serveur (par exemple, pour stocker / récupérer des données relatives aux plug-ins) ainsi que des sorties côté client. Angular 2/4/5 particulier (et fortement), décourage les développeurs d’injecter leurs propres modèles lors de l’exécution, car cela pose un grave problème de sécurité. Afin de gérer de nombreux types de sortie qu’un plugin peut accepter (par exemple l’affichage d’un graphique), il semble que permettre aux utilisateurs de créer du contenu qui est injecté dans le stream de réponse, sous une forme ou une autre, est probablement nécessaire. Je me demande comment il serait possible de répondre à ce besoin sans déchiqueter figurativement les mécanismes de sécurité Angular 2/4/5/6 .

• La plupart des applications Angular 2/4/5/6 production sont pré-compilées en utilisant la compilation Ahead of Time ( AOT ). (Tout devrait probablement l’être.) Je ne sais pas comment les plug-ins peuvent être ajoutés (ou intégrés) aux applications pré-compilées. Le meilleur scénario impliquerait la compilation des plug-ins séparément de l’application principale. Cependant, je ne sais pas comment faire ce travail. Une solution de rechange pourrait consister à recomstackr l’application entière avec tous les plugins inclus, mais cela compliquerait un peu les choses pour un administrateur qui veut simplement installer l’application (sur son propre serveur) avec tous les plugins sélectionnés.

• Dans une application Angular 2/4/5/6 , en particulier une application pré-compilée, un seul code erratique ou conflictuel peut casser l’application entière. Angular 2/4/5/6 applications Angular 2/4/5/6 ne sont pas toujours les plus faciles à déboguer. L’application de plugins mal conduits pourrait entraîner des expériences très désagréables. Je ne suis actuellement pas au courant d’un mécanisme pour gérer avec élégance les plugins mal conduits.

 import {Component} from '@angular/core'; import {Router} from '@angular/router'; @Component({ selector: 'my-app', template: ` Home | App Home | App Lazy 
 Add Routes 
  ` }) export class App { loaded: boolean = false; constructor(private router: Router) {} addRoutes() { let routerConfig = this.router.config; if (!this.loaded) { routerConfig[1].children.push({ path: `lazy`, loadChildren: 'app/lazy.module#LazyModule' }); this.router.resetConfig(routerConfig); this.loaded = true; } } } 

  const moduleFile: any = require(`./${app}/${app}.module`), module = moduleFile[Object.keys(moduleFile)[0]]; route.children.push({ path: app, loadChildren: (): Promise => module }); promises.push(this.comstackr.comstackModuleAndAllComponentsAsync(module)); 

 { provide: APP_INITIALIZER, useFactory: AppsLoaderFactory, deps: [AppsLoader], multi: true }, 

 declare var ctx: any; @Component({ selector: 'my-template', template: ` 
 
 
 `, providers: [EmitterService], }) export class MyTemplateComponent implements OnMount, AfterViewInit, OnChanges { // name private _name: ssortingng; get name(): ssortingng { return this._name; } @Input() set name(name: ssortingng) { this._name = name; this.initTemplate(); } template: ssortingng; ctx: any = null; private initTemplate() { this.templateSvc.getTemplate(this.name).subscribe(res => { // Load external JS with ctx implementation let promise1 = injectScript(res.pathJs); // Load external CCS let promise2 = injectScript(res.pathCss); Promise.all([promise1, promise2]).then(() => { // assign external component code this.ctx = ctx; // // sets the template this.template = res.template; this.injectServices(); if (this.ctx && this.ctx.onInit) { this.ctx.onInit(); } }); }); } 

 var ctx = { // injected _httpService: {}, _emitterService: null, // properies model: { "title": "hello world!", }, // events onInit() { console.log('onInit'); }, onDestroy() { console.log('onDestroy'); }, onChanges(changes) { console.log('changes', changes); }, customFunction1() { console.log('customFunction1'); }, childTemplateName: ssortingng = 'other-component'; }; 

 {{ ctx.model.title }}  

 {{ ctx.model.title }}  

 var map = { "./dashboard/dashboard.module": ["../../../../../src/app/dashboard/dashboard.module.ts","dashboard.module"]};