Реализация архитектуры плагинов / системы плагинов / плагин-фреймворка в Angular 2, 4, 5, 6

Обновление от 24.05.2008: У нас сейчас +3 версии Angular из моего исходного поста, и у нас до сих пор нет окончательного работоспособного решения. Ларс Мейдам (@LarsMeijdam) предложил интересный подход, который, безусловно, стоит посмотреть. (Из-за проблем с собственностью ему пришлось временно удалить репозиторий GitHub, в котором он изначально разместил свой образец. Однако вы можете написать ему напрямую, если хотите получить копию. Дополнительные сведения см. В комментариях ниже.)

Недавние архитектурные изменения в Angular 6 действительно приближают нас к решению. Кроме того, Angular Elements ( https://angular.io/guide/elements ) предоставляет некоторые функциональные возможности компонента - хотя и не совсем то, что я первоначально описал в этом посте.

Если кто-то из удивительной команды Angular случайно сталкивался с этим, обратите внимание, что, похоже, есть много других людей, которые также очень заинтересованы в этой функциональности. Возможно, стоит подумать об отставании.

Я хотел бы реализовать подключаемые (плагин) рамки в качестве Angular 2, Angular 4, Angular 5или Angular 6приложении.

(Мой конкретный вариант использования для разработки этой подключаемой инфраструктуры заключается в том, что мне нужно разработать миниатюрную систему управления контентом. По ряду причин, которые не обязательно подробно описаны здесь, Angular 2/4/5/6она почти идеально подходит для большинства потребностей этой системы.)

Под подключаемой структурой (или подключаемой архитектурой) я конкретно имею в виду систему, которая позволяет сторонним разработчикам создавать или расширять функциональность основного приложения за счет использования подключаемых компонентов, не имея прямого доступа или знания исходного кода основного приложения. или внутренняя работа .

(Эта формулировка о том, что « не имея прямого доступа к исходному коду или внутренним принципам работы или знания этих программ », является основной целью.)

Примеры подключаемых платформ включают в себя общие системы управления контентом, такие как WordPressили Drupal.

Идеальная ситуация (как и в случае с Drupal) - это просто иметь возможность поместить эти подключаемые компоненты (или подключаемые модули) в папку, чтобы приложение автоматически обнаруживало или обнаруживало их, и они просто волшебным образом «работали». Если бы это происходило каким-то образом с возможностью «горячей» замены, то есть во время работы приложения было бы оптимальным.

В настоящее время я пытаюсь определить ответы ( с вашей помощью ) на следующие пять вопросов.

1. Практичность: действительно ли плагин-фреймворк для Angular 2/4/5/6приложения практичен? (До сих пор я не нашел практического способа создать действительно подключаемый фреймворк с Angular2/4/5/6.)
2. Ожидаемые проблемы: с какими проблемами можно столкнуться при реализации инфраструктуры плагинов для Angular 2/4/5/6приложения?
3. Стратегии реализации: Какие конкретные методы или стратегии могут быть использованы для реализации инфраструктуры плагинов для Angular 2/4/5/6приложения?
4. Рекомендации: каковы рекомендации по внедрению системы плагинов для Angular 2/4/5/6приложения?
5. Альтернативные технологии: если плагинная структура неAngular 2/4/5/6 применима в приложении, какие относительно эквивалентные технологии (например React) могут подойти для современного высокореактивного веб-приложения ?

В общем, использование Angular 2/4/5/6очень желательно, потому что:

• это естественно очень быстро - чертовски так.
• он потребляет очень небольшую пропускную способность (после начальной загрузки)
• он имеет относительно небольшой след (после AOTи tree shaking) - и этот след продолжает сокращаться
• это очень функциональный, и команда и сообщество Angular продолжают быстрый рост своей экосистемы
• он хорошо сочетается со многими лучшими и новейшими веб-технологиями, такими как TypeScriptиObservables
• Angular 5 теперь поддерживает сервисных работников ( https://medium.com/@webmaxru/a-new-angular-service-worker-creating-automatic-progressive-web-apps-part-1-theory-37d7d7647cc7 )
• опираясь на него Google, он, вероятно, будет поддерживаться и улучшаться в будущем

Я бы очень хотел использовать Angular 2/4/5/6для своего текущего проекта. Если я смогу использовать Angular 2/4/5/6, я также буду использовать Angular-CLIи, вероятно, Angular Universal(для рендеринга на стороне сервера).

Вот мои мысли, что касается вопросов выше. Пожалуйста, просмотрите и поделитесь своим мнением и мнением.

• Angular 2/4/5/6приложения используют пакеты, но это не обязательно то же самое, что разрешать плагины в приложении. Плагин в других системах (например Drupal) может быть по существу добавлен путем перетаскивания папки плагина в общий каталог модулей, где он автоматически "подбирается" системой. В Angular 2/4/5/6пакет (как и плагин) обычно устанавливается через npm, добавляется в package.json, а затем вручную импортируется в приложение - как в app.module. Это намного сложнее, чем Drupalметод удаления папки и автоматического обнаружения системой пакета. Чем сложнее установить плагин, тем менее вероятно, что люди будут его использовать. Было бы намного лучше, если бы был способAngular 2/4/5/6автоматически обнаруживать и устанавливать плагины. Мне очень интересно найти метод, который позволит людям, не являющимся разработчиками, устанавливать Angular 2/4/5/6приложение и устанавливать любые выбранные плагины без необходимости понимать всю архитектуру приложения.

• Как правило, одним из преимуществ предоставления подключаемой архитектуры является то, что сторонним разработчикам очень легко расширить функциональные возможности системы. Очевидно, что эти разработчики не будут знакомы со всеми тонкостями кода для приложения, к которому они подключаются. Как только плагины разработаны, другие, даже менее технические пользователи могут просто установить приложение и любые выбранные плагины. Однако Angular 2/4/5/6это относительно сложно и требует очень длительного обучения. Чтобы еще более усложнить вещи, большинство производственных Angular 2/4/5/6приложений также используют Angular-CLI, Angular Universalи WebPack. Кто-то, кто реализует плагин, вероятно, должен был бы иметь хотя бы некоторые базовые знания о том, как все они сочетаются друг с другом - наряду с сильным рабочим знаниемTypeScriptи разумное знакомство с NodeJS. Являются ли требования к знаниям настолько экстремальными, что ни одна третья сторона никогда не захочет разработать плагин?

• Большинство плагинов, вероятно, будут иметь некоторый компонент на стороне сервера (например, для хранения / извлечения данных, связанных с плагином), а также некоторые выходные данные на стороне клиента. Angular 2/4/5в частности (и строго) отговаривает разработчиков внедрять свои собственные шаблоны во время выполнения - так как это создает серьезную угрозу безопасности. Чтобы обрабатывать многие типы вывода, которые может поддерживать плагин (например, отображение графика), кажется, что, вероятно, необходимо разрешить пользователям создавать контент, который вводится в поток ответов в одной форме в другой. Интересно, как можно было бы удовлетворить эту потребность без изобразительного уничтожения Angular 2/4/5/6механизмов безопасности.

• Большинство производственных Angular 2/4/5/6приложений предварительно скомпилированы с использованием Ahead of Time( AOT) компиляции. (Вероятно, все должно быть.) Я не уверен, как плагины могут быть добавлены (или интегрированы) в предварительно скомпилированные приложения. Лучший сценарий - компиляция плагинов отдельно от основного приложения. Однако я не уверен, как это сделать. Резервным вариантом может быть повторная компиляция всего приложения с любыми включенными плагинами, но это немного усложняет ситуацию для пользователя с правами администратора, который просто хочет установить приложение (на своем собственном сервере) вместе с любыми выбранными плагинами.

• В Angular 2/4/5/6приложении, особенно предварительно скомпилированном, один фрагмент ошибочного или конфликтующего кода может нарушить работу всего приложения. Angular 2/4/5/6приложения не всегда легче всего отлаживать. Применение некорректных плагинов может привести к очень неприятным результатам. В настоящее время я не знаю о механизме корректной обработки некорректных плагинов.

Я создал репозиторий на github с решением, которое может помочь. Он использует 6 библиотек Angular и 1 базовое приложение, которые лениво загружают связанные библиотеки UMD; https://github.com/lmeijdam/angular-umd-dynamic-example

Если у вас есть какие-либо предложения, пожалуйста, не стесняйтесь добавлять!

🛠️ Демо - версия Github angular-plugin-architecture

Возможно, Айви может что-то изменить, но пока я использую решение, использующее Angular CLI Custom Builder и отвечающее следующим требованиям:

• АОТ
• избегайте дублирования кода (такие пакеты, как @ angular / core {common, forms, router}, rxjs, tslib)
• использовать общую библиотеку во всех подключаемых модулях, но НЕ ОТПРАВЛЯЙТЕ созданные фабрики из этой общей библиотеки в каждом подключаемом модуле, а используйте повторно код библиотеки и фабрики
• тот же уровень оптимизации, который дает нам Angular CLI
• для импорта внешних модулей нам нужно знать только одно: путь к пакетному файлу
• наш код должен распознать модуль и разместить плагин на странице
• поддержка рендеринга на стороне сервера
• загружать модуль только при необходимости

Использование простое как:

ng build --project plugins --prod --modulePath=./plugin1/plugin1.module#Plugin1Module 
         --pluginName=plugin1 --sharedLibs=shared --outputPath=./src/assets/plugins

Подробнее об этом в моей статье:

• Создание расширяемого динамического подключаемого корпоративного приложения с помощью Angular

Я только что опубликовал новую главу для своей книги « Разработка с помощью Angular », которая посвящена теме плагинов в Angular 2+ и должна представлять большой интерес для людей, которые пытаются создавать внешние плагины.

Ключевые моменты:

• Плагины
• Создание компонентов на основе имен строк
• Загрузка конфигурации из внешних источников
• Динамически меняющиеся маршруты приложений
• Внешние плагины
• Создание библиотек плагинов
• Загрузка плагинов в приложение
• Динамические маршруты с содержимым плагина

Книгу можно получить бесплатно, и в ней есть модель «плати сколько хочешь». Не стесняйтесь взять копию и надеюсь, что это поможет.

Пример приложения с работающей системой плагинов (спасибо Gijs за создание репозитория github!) На основе https://github.com/PacktPublishing/Mastering-Angular-2-Components/tree/master/angular-2-components-chapter-10 на электронную книгу Мастеринг Angular 2 Компоненты

• архитектура плагинов для расширения основных компонентов приложения
• файловая система плагинов (для простого добавления каталогов / файлов плагинов без редактирования каких-либо основных конфигурационных файлов или необходимости перекомпилировать ваше приложение!)
• загружать и динамически использовать плагины
• создание рудиментарного диспетчера плагинов для активации / деактивации плагинов на лету

Ура, Никлас

То, что вы ищете, это ленивая загрузка модуля. Вот пример: http://plnkr.co/edit/FDaiDvklexT68BTaNqvE?p=preview

import {Component} from '@angular/core';
import {Router} from '@angular/router';

@Component({
  selector: 'my-app',
  template: `
    <a [routerLink]="['/']">Home</a> | 
    <a [routerLink]="['/app/home']">App Home</a> |
    <a [routerLink]="['/app/lazy']">App Lazy</a>

    <hr>
    <button (click)="addRoutes()">Add Routes</button>

    <hr>
    <router-outlet></router-outlet>
  `
})
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<any> => module
 });
 promises.push(this.compiler.compileModuleAndAllComponentsAsync(module));

затем в AppModule добавьте это:

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

Я искал систему плагинов в угловой версии 2/4 для разработки среды RAD для корпоративного приложения на работе. После некоторых исследований я решил реализовать набор хранящихся в базе данных (но могущих быть в файловой системе) псевдо-угловых компонентов.

Компоненты, хранящиеся в базе данных базы данных, основаны на ng-dynamic, и реализация основного компонента похожа на это:

declare var ctx: any;

@Component({
    selector: 'my-template',
    template: `
<div>
    <div *dynamicComponent="template; context: { ctx: ctx };"></div>
</div>
  `,
    providers: [EmitterService],

})

export class MyTemplateComponent implements OnMount, AfterViewInit, OnChanges {


    // name
    private _name: string;
    get name(): string {
        return this._name;
    }
    @Input()
    set name(name: string) {
        this._name = name;        
        this.initTemplate();
    }

    template: string;
    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();
                }

            });

        });

    }

Внешний код javascript аналогичен угловым компонентам:

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: string = 'other-component'; 

};

А шаблоны компонентов похожи на угловые шаблоны:

<a (click)="customFunction1()">{{ ctx.model.title }}</a>
<input [(ngModel)]="ctx.model.title" type="text" />

И тоже может быть вложенным:

<a (click)="customFunction1()">{{ ctx.model.title }}</a>
<my-template [name]="childTemplateName"></my-template>

Хотя это не идеально, разработчики пользовательских компонентов имеют аналогичную структуру, чем в angular2 / 4.

Это можно сделать «вручную». Поскольку веб-пакет ничего не знает о внешнем (подключаемом) модуле, он не может включить их в комплект (ы). Итак, я посмотрел на код, сгенерированный webpack, и нашел этот кусок кода в main.bundle.js:

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

Давайте посмотрим, что содержит этот массив:

1. "./dashboard/dashboard.module" - это URL-адрес маршрутизации модуля, который мы хотим отложить, например: {path: 'dashboard', loadChildren: './dashboard/dashboard.module#DashboardModule'}
2. «../../../../../src/app/dashboard/dashboard.module.ts» - это точка входа (конструктор)
3. «dashboard.module» - фактическое имя файла без chunk.js (например, dashboard.module.chunk.js )

Таким образом, теоретически, если вы добавите запись в свойство карты, сконфигурируете свою маршрутизацию и будете следовать шаблону, вы можете иметь систему плагинов. Теперь задача состоит в том, как добавить или удалить записи из этого свойства карты. Очевидно, что это не может быть сделано из углового кода, это должно быть сделано для внешнего инструмента.

Я попытался реализовать архитектуру плагинов, используя ABP, Angular и ASP.NET Core: https://github.com/chanjunweimy/abp_plugin_with_ui

По сути, я разработал угловые плагины, используя различные угловые приложения, а затем динамически складываю их вместе.

Больше информации о том, как я этого добиваюсь:

У меня есть 2 приложения angular-cli, 1 - основное приложение angular cli, а другое - плагин angular cli. Проблема, с которой мы сталкиваемся в подходе к архитектуре плагинов Angular-Cli, заключается в том, как мы их интегрируем.

Прямо сейчас я запустил ng-build для обоих приложений и поместил их в папку «wwwroot», которая затем размещалась на сервере ASP.NET core 2.0. Более простым репозиторием, демонстрирующим эту идею, является Angular Multiple App: https://github.com/chanjunweimy/angular-multiple-app.

abp_plugin_with_ui - это репозиторий, который работает над разработкой плагина, который содержит как бэкэнд, так и Angular cli. В качестве бэкэнда я использовал инфраструктуру aspnetboilerplate, интерфейс которой разработан с использованием приложения angular-cli.

Чтобы интегрировать основное приложение с приложением плагина, мы должны запустить «ng-build» в обоих приложениях (обратите внимание, что мы также должны перейти на href приложения плагина), затем мы перемещаем встроенное содержимое плагина приложение angular cli, к основной папке приложения "wwwroot". После достижения всего этого мы можем запустить «запуск по сети» для обслуживания веб-приложения ASP.NET Core 2.0 для размещения статических файлов, созданных «ng build».

Надеюсь, это поможет. Любые комментарии приветствуются! ^^

Немного не по теме, но библиотеки компонентов пользовательского интерфейса могут представлять интерес для некоторых читателей, которые ищут плагины:
https://medium.com/@nikolasleblanc/building-an-angular-4-component-library-with-the -angular-кли-и-нг-packagr-53b2ade0701e

NativeScript имеет встроенные плагины пользовательского интерфейса:
https://docs.nativescript.org/plugins/building-plugins
Этим плагинам требуется Angular Wrapper:
https://docs.nativescript.org/plugins/angular-plugin

В настоящее время я нахожусь в том же квесте, что и вы, пытаясь сделать Pluggable / Themable версию Angular, и это не тривиальная проблема.

На самом деле я нашел довольно хорошие решения, читая книгу Genius Denys Vuyika « Developing with Angular » , он на самом деле в книге объясняет довольно хорошее решение, рассказывает о внешних плагинах на странице 356 книги и использует Rollup.js для достижения После этого он выполняет процесс динамической загрузки внешних подключаемых модулей, которые ранее были созданы вне вашего приложения.

Есть также две другие библиотеки / проекты, которые помогут вам достичь этого результата. Ng-packagr и расширения Nx для Agnular (от Nrwl), которые мы связываем для реализации последнего, и я бы сказал, что это не так гладко, как мы ожидали, angular был простым не для этого, поэтому нам нужно обойти некоторые основные аспекты Angular, и NX ppls являются одними из лучших в этом.

Мы находимся только в начале нашего проекта с открытым исходным кодом, мы используем Django + Mongo + Angular, (мы вызываем WebDjangular, и один из наших возможных подходов к этому ответу заключается в том, что Django придется написать несколько файлов конфигурации JSON и собрать приложение каждый раз, когда устанавливается и активируется новый плагин или тема.

Мы уже сделали то, что из базы данных мы можем использовать теги для компонентов, как на плагине, и компонент будет напечатан на экране! Опять же, проект находится на очень ранних стадиях, мы немного основываем нашу архитектуру на Wordpress, и у нас еще много тестов, чтобы осуществить нашу мечту: D

Надеюсь, что Книга поможет вам, и, используя Rollup.js, я знаю, что вы сможете решить эту нетривиальную проблему.

Я нашел хорошую статью от Пола Ионеску о том, как создать расширяемое приложение для плагинов в angular.

https://itnext.io/how-to-build-a-plugin-extensible-application-architecture-in-angular5-736890278f3f

Он также ссылается на пример приложения на github: https://github.com/ionepaul/angular-plugin-architecture