Реалізація архітектури плагінів / системи плагінів / підключається рамки в кутових 2, 4, 5, 6

Оновлення 24.05.2018: Зараз ми отримуємо +3 версії Angular від моєї оригінальної публікації і досі не маємо остаточного рішення. Ларс Мейддам (@LarsMeijdam) придумав цікавий підхід, який, безумовно, варто подивитися. (Через проблеми, що стосуються власності, йому довелося тимчасово видалити сховище GitHub, де він первісно розмістив зразок. Однак ви можете надіслати йому повідомлення безпосередньо, якщо вам потрібна копія. Щоб отримати докладнішу інформацію, перегляньте коментарі нижче.)

Недавні архітектурні зміни в кутовій 6 наблизили нас до рішення. Крім того, кутові елементи ( 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 кутових бібліотек та 1 базову програму, які ліниво завантажують бібліотеки, що входять до UMD; https://github.com/lmeijdam/angular-umd-dynamic-example

Якщо у вас є якісь пропозиції, не соромтесь додавати!

Demo Демо- кутова архітектура Github

Можливо, Ivy може щось змінити, але поки що я використовую рішення, яке використовує Angular CLI Custom Builder і відповідає таким вимогам:

• AOT
• уникайте повторюваного коду (такі пакети, як @ angular / core {загальні, форми, маршрутизатор}, rxjs, tslib)
• використовувати спільну бібліотеку у всіх плагінах, але НЕ ДОСТАВКАйте створені фабрики із цієї спільної бібліотеки у кожному плагіні, а скоріше використовуйте код бібліотеки та фабрики
• той же рівень оптимізації, який дає нам Angular CLI
• для імпорту зовнішніх модулів нам просто потрібно знати лише одне: їх шлях до файлу пакетів
• наш код повинен розпізнати модуль і розмістити плагін на сторінці
• підтримка візуалізації на стороні сервера
• модуль завантаження лише за потреби

Використання просте, як:

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

Детальніше про це в моїй статті:

• Побудова розширюваного динамічного підключення корпоративного додатку з кутовим

Щойно я опублікував нову главу для своєї книги " Розвиток з кутовими ", яка стосується теми плагінів у програмі Angular 2+ і має цікавити людей, які намагаються створити зовнішні плагіни.

Ключові моменти:

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

Книга дістається безкоштовно і має модель "платити, що ти хочеш". Не соромтеся взяти копію та сподівайтеся, що це допоможе.

Приклад додаток з робочою системою плагіна (завдяки Гісу для заснування GitHub репо!) Https://github.com/PacktPublishing/Mastering-Angular-2-Components/tree/master/angular-2-components-chapter-10 основи на компоненти електронної книги Mastering 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-динаміці, і реалізація основного компонента аналогічна цьому:

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, полягає в тому, як ми їх інтегруємо.

Зараз, що я і робив, я запускаю ng-build для обох програм і вкладаю їх у папку "wwwroot", яка потім розміщується на сервері ASP.NET core 2.0. Більш простий сховище, яке показує цю ідею, - Angular Multiple App: https://github.com/chanjunweimy/angular-multiple-app

abp_plugin_with_ui - це сховище, яке працює над розробкою плагіна, який містить як резервний, так і кутовий кліпи. Для бекенда я скористався рамкою aspnetboilerplate, яка розробляється за допомогою декількох додатків angular-cli.

Щоб інтегрувати основну програму з додатком плагінів, нам потрібно запустити "ng-build" на обох програмах (зауважте, що ми також повинні змінити href додатка плагіну), а потім перемістимо вбудований вміст плагіна кутовий додаток cli, в основну папку "wwwroot". Досягнувши всього цього, ми можемо запустити "запуск дотнету", щоб обслуговувати веб-додаток ASP.NET Core 2.0 для розміщення статичних файлів, створених "ng build".

Сподіваємось, це допомагає. Будь-які коментарі вітаються! ^^

Трохи поза темою, але бібліотеки компонентів інтерфейсу можуть зацікавити деяких читачів, які шукають плагіни:
https://medium.com/@nikolasleblanc/building-an-angular-4-component-library-with-the -angular-cli-and-ng-packgr-53b2ade0701e

NativeScript має вбудовані плагіни інтерфейсу користувача:
https://docs.nativescript.org/plugins/building-plugins
Ці плагіни потребують кутової обгортці:
https://docs.nativescript.org/plugins/angular-plugin

Я зараз перебуваю в тому ж самому квесті, що і ви, намагаючись зробити Pluggable / Themable версію Angular, і це не тривіальна проблема.

Я насправді знайшов досить хороші рішення, читаючи книгу « Розвивається з кутовим» від Genius Denys Vuyika , він насправді на книгу пояснює досить вдале рішення, він розповідає про зовнішні плагіни на сторінці 356 книги та використовує Rollup.js для досягнення рішення, потім він обробляє динамічне завантаження зовнішніх плагінів, які раніше були побудовані поза вашої програми.

Є також дві інші бібліотеки / проекти, які допомагають досягти цього результату ng-packgr та Nx розширення для Agnular (від Nrwl), ми прив'язуємося до реалізації останнього, і я б сказав, що це не так гладко, як ми передбачали, кутовий був простий не побудований для цього, тому нам доведеться обходити деякі основні принципи того, як Angular та NX ppls є одними з найкращих.

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

Що ми вже зробили, це те, що з бази даних ми можемо використовувати теги для таких компонентів, як у плагіні, і компонент буде надрукований на екрані! Знову ж проект знаходиться на дуже ранніх стадіях, ми базуємо свою архітектуру трохи на Wordpress, і у нас є ще багато тестів, які потрібно зробити, щоб досягти своєї мрії: D

Я сподіваюся, що Книга може допомогти вам, і за допомогою Rollup.js я знаю, що ви зможете зламати цю нетривіальну проблему.

Я знайшов хорошу статтю від Пола Іонеску про те, як побудувати додаток, що розширюється, у кутовій.

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

Він також посилається на приклад програми на github: https://github.com/ionepaul/angular-plugin-architecture