Как реализовать архитектуру на основе плагинов с использованием приставки

Question

Я работаю над веб-приложением, в котором пользователь может подписаться на доступные функции, и все эти функции оказывают определенное влияние на действия пользователя. Я использую Redux Thunk для асинхронных действий.

например. пользователь может выбрать продукт для покупки или продажи из списка продуктов, при этом запускается редуктор с именем userIntention, после чего вызывается редуктор createProductForm, который отображает форму продукта вместе с информацией о продукте. Пользователь может подписаться на такие функции, как рекомендации, лучшие предложения и т. Д., Которые могут изменять определенные параметры свойств продукта, такие как теги, цена. Я хочу реализовать это таким образом, чтобы в случае запуска createProductForm редуктор собирал данные из рекомендаций, лучших предложений и т. Д. Динамически и на основании полученных результатов формировал форму продукта пользователя.

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

Это похоже на плагин, где подписка активирует некоторые редукторы и промежуточное ПО.

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

Что я пробовал:

1. После подписки на функцию отправляется действие под названием «ENABLE_FEATURE», которое редукторы функции могут прослушивать, динамически регистрируя себя. Но мне трудно поддерживать, какие редукторы вызывать. Есть ли способ сохранить список редукторов в магазине редуксов.
2. То же самое пробовали с промежуточным ПО, но затем динамическое удаление одного из промежуточного ПО слишком сложно.
3. создайте мою собственную утилиту за пределами системы редукции, где будет реализована регистрация, подписка на динамические редукторы, а затем как вызывать редукторы из-за пределов реагирующего компонента, поскольку отправка и сохранение недоступны.

Мы используем rekit studio для разработки.

EDIT Это моя прикладная архитектура. Как видите, все функции разрабатываются независимо друг от друга, наряду с редукторами, магазином, компонентами. Что нам нужно, так это когда компонент f-core разработан, он не тронут, даже если мы реализуем новые функции независимо от него. Что-то вроде реестра, в котором функции могут регистрироваться, поэтому f-core узнает об их существовании. Тогда эти функции должны были раскрыть некоторые функции (редукторы), которые будут определены во время выполнения. Архитектура приложения

/node_modules
package.json
package-lock.json
/public
/src
 - /common
     - configStore.js
     - history.js
     - rootReducer.js
     - routeConfig.js
 - /features
    - /f-core
        - component1.js
         - component1.less
         - index.js
         - route.js
         - /api-service
             - router.js
             - constants.js
             - service.js
         - /redux
             - actions.js
             - constants.js
             - reducer.js
             - initialState.js
             - reducer1.js
     - /f1
         - component1.js
         - component1.less
         - index.js
         - route.js
         - /api-service
             - router.js
             - constants.js
             - service.js
         - /redux
             - actions.js
             - constants.js
             - reducer.js
             - initialState.js
             - reducer1.js
     - /f2
        - component1.js
            - component1.less
         - index.js
         - route.js
         - /api-service
             - router.js
             - constants.js
             - service.js
         - /redux
             - actions.js
             - constants.js
             - reducer.js
             - initialState.js
             - reducer1.js
 - index.js
 - Root.js

Answer 1

Один из способов разработки подключаемых подсостояний Redux изолированно: 1) записать каждое подсостояние с нулевыми внешними зависимостями, а затем 2) в основном приложении использовать Redux-Saga для организации потоков действий, пересекающих подключаемые границы подсостояния.

1) Записать каждое подсостояние с нулевыми зависимостями, ссылаясь только на функции, переменные и т. Д. В своем собственном пространстве имен / directory / plugin. Значение:

• Совместимость всего связанного кода, такого как редукторы, типы действий, создатели действий, селекторы, константы, утилиты
• Редукторы обрабатывают только колокейные типы действий
• Селекторы извлекаются только из совместного состояния

2) Используйте Redux-Saga для организации потоков действий, которые пересекают границы между штатами. Если редукторам из отдельных плагинов необходимо обновить состояние для одного и того же события, сделайте сагу, прослушивающую действие приложения / не подключаемого модуля, а затем отправьте отдельные специфичные для плагина действия.

Пример:

import { CREATE_ITEM } from '../actions'; // i.e. src/actions
import { moduleA, moduleB } from '../modules';

export function* onCreateItem() {
    yield takeEvery(CREATE_ITEM, function* ({ item }) {
        yield put(moduleA.actionCreators.addNewItem(item));
        yield put(moduleB.actionCreators.setMostRecentlyCreatedItem(item.name));
    })
}

С этим шаблоном Redux-Saga становится слоем перенаправления между действиями конкретного приложения и независимыми от приложения подсостояниями, так что каждое из них может изменяться независимо.

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

Вопросы:

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