Статьи

Создание архитектуры внешнего интерфейса с динамическими плагинами

Ниже приведены некоторые из наиболее часто используемых подходов для обработки подключаемости в веб-интерфейсе:

  1. Основное приложение работает как макет для всех функций, которые оно содержит, где каждая функция имеет функцию включения / выключения. Если плагин присутствует, он будет отображаться в определенном месте. Но если вы хотите разработать новый плагин, вам нужно будет изменить основное приложение, чтобы оно было в курсе этого.
  2. Динамически загружайте плагины и добавляйте их в основное приложение в качестве вложенных приложений в iframe . Это дает определенную гибкость, поскольку вы можете использовать разные версии одних и тех же сторонних библиотек, но есть и некоторые затраты, в том числе:

    • Размер пучка дует очень быстро. Все необходимые сторонние плагины должны быть снова включены в плагин.
    • Чтобы повторно использовать уже написанную логику в базовом плагине, вы должны либо скопировать и вставить его, либо создать общий модуль с общей функциональностью и включить его в ядро ​​и пользовательский плагин. В этом последнем сценарии, когда эта общая функциональность отличается от плагина к плагину, она может очень быстро стать беспорядком. 
    • Это не позволит вам вносить небольшие изменения в приложение, такие как замена кнопки новой на лету.

Помня об этих ограничениях, давайте взглянем на новый подход. Сначала я объясню это на простом примере, а затем на более продвинутом уровне.


Вам также может понравиться:
Основы Redux .

В качестве простого примера мы можем смоделировать приложение, в котором все пользовательские плагины будут автоматически зарегистрированы на панели навигации. Давайте посмотрим на панель навигации внутри нашего основного основного плагина пользовательского интерфейса:

Пример навигационной панели

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

  • Мы должны определить, как мы собираемся обнаруживать плагины пользовательского интерфейса среди других типов плагинов.
  • Каждый плагин должен содержать метаданные в едином формате:

    • Дайте название плагину на панели навигации.
    • Определите место для вкладки; в противном случае порядок пользовательских вкладок будет неуправляемым.
    • Укажите расположение пакетов, которые будут загружены на страницу.
    • Определите разрешения и загрузите плагины в зависимости от роли.
  • Создайте канал связи на основе событий между основным приложением и плагином и между плагинами.

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

Имея в виду эти требования, давайте попробуем углубиться в детали и сделать нашу панель такой (после загрузки пользовательского плагина):

Навбар с новым плагином

Как вы могли заметить, на второй позиции панели навигации добавлена ​​дополнительная вкладка «Отчеты». 

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

Для этого мы можем добавить файловый дескриптор к каждому плагину пользовательского интерфейса, который будет указывать, что это пользовательский плагин пользовательского интерфейса, то есть custom-ui-extension.json . При этом, когда мы сканируем папку / classpath, мы можем фильтровать новые плагины.

Каждый плагин должен содержать метаданные в едином формате.

Давайте спроектируем, как это может выглядеть для вышеупомянутых требований:


JSON