Как поделиться хранилищем redux в архитектуре микро-интерфейса?

Question

Я пытаюсь создать небольшой проект по реализации архитектуры микро-интерфейса, следуя статье Micro Frontends . Я создаю несколько репозиториев для каждого MFE (Micro-интерфейс), а также использую Redux для приложения. У меня следующая архитектура:

1. Frame - централизованное (основное) репо, которое отвечает за рендеринг основной части приложения и MFE на основе маршрутизации (я использую connected-react-router). Он инициализирует хранилище Redux, а также добавляет функцию injectReducer для динамического добавления редукторов, как описано в разделении кода в документации redux . Фрейм извлекает манифест для конкретного MFE и отображает его. Во фрейме также есть некоторые данные redux для аутентификации.
2. MFEs - это отдельные приложения с функциями, которые отображаются по кадрам.

Теперь у меня проблема, Я хочу использовать функцию injectReducer в своих MFE для динамического добавления редукторов для хранения. Для этого мне нужен доступ к тому же экземпляру store, который создается кадром. Как упоминалось в этот ответ , идеальный способ - экспортировать созданный экземпляр хранилища и использовать его, но как мы можем совместно использовать один и тот же экземпляр хранилища в нескольких репозиториях?

Answer 1

В статье есть комментарий, прямо касающийся этого:

Если вы используете redux, обычный подход состоит в том, чтобы иметь единое глобальное разделяемое хранилище для всего приложения. Однако, если предполагается, что каждый микро-интерфейс является отдельным автономным приложением, то для каждого из них имеет смысл иметь собственное хранилище redux. В документации redux даже упоминается «изоляция приложения Redux как компонента в более крупном приложении» как веская причина иметь несколько хранилищ.

Короче говоря: не делитесь своим хранилищем redux

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