Общий доступ к состоянию и маршрутизации между удалёнными приложениями

Каждое удалённое приложение Module Federation собирается и развёртывается независимо. Его состояние (React useState, контекст и хранилища Zustand) находится в собственной области видимости модуля JavaScript. Хост и удалённые приложения не используют состояние автоматически — архитектуру совместного использования необходимо продумать явно.

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

CustomEvents через браузерный EventTarget позволяют удалённым приложениям обмениваться данными без прямого импорта. Одно удалённое приложение вызывает window.dispatchEvent(new CustomEvent('cart:updated', { detail: cart })), а любой другой модуль (хост или другое удалённое приложение) подписывается с помощью window.addEventListener('cart:updated', handler). Общий модуль не нужен.

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

Оболочка (хост) владеет всем общим состоянием и передаёт его удалённым приложениям в виде свойств или через контекст. Удалённые приложения получают такие функции обратного вызова, как onCartUpdate, и выполняют навигацию через свойства. Это сохраняет состояние централизованным в хосте, но требует, чтобы хост знал API удалённых приложений, создавая тесную связанность.

Состояние истории и текущего адреса React Router предоставляется компонентом маршрутизатора (BrowserRouter или createBrowserRouter). В конфигурации Module Federation должен быть ровно один маршрутизатор — размещение его в каждом удалённом приложении создаст несколько конкурирующих контекстов маршрутизации и приведёт к конфликтам навигации.

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

Значения контекста React связаны с конкретным экземпляром React и объектом контекста. Чтобы контекст работал между хостом и удалённым приложением, оба должны импортировать один и тот же объект контекста из одного источника — обычно из общего удалённого приложения состояния или общего пакета утилит. Синглтон React гарантирует, что один и тот же контекст будет работать во всех удалённых приложениях.

В хорошо организованной архитектуре Module Federation оболочка (хост) отвечает за HTML-оболочку, провайдер маршрутизатора, контекст аутентификации, провайдер темы и токенов дизайна, а также глобальную навигацию. Удалённые приложения отвечают за содержимое своих функциональных областей. Оболочка объединяет удалённые приложения в макет, не зная деталей их реализации.

Самый серьёзный антипаттерн Module Federation — тесная связанность хоста и удалённого приложения: хост импортирует типы из удалённого приложения, удалённое приложение импортирует компоненты из хоста или они используют общий пакет npm, который обоим приходится обновлять одновременно. Такая связанность сводит на нет преимущество независимого развёртывания.

Определите явные контракты между хостом и удалёнными приложениями: свойства, которые принимает компонент удалённого приложения, события CustomEvents, которые он вызывает, и параметры URL, которые он читает. Документируйте эти контракты как интерфейсы TypeScript в общем пакете типов. Это позволяет командам развиваться независимо в рамках согласованного контракта.

Где следует размещать провайдер React Router (BrowserRouter) в архитектуре Module Federation?

Для совместного использования состояния между удалёнными приложениями Module Federation можно применять состояние в URL (самый простой вариант), CustomEvents (слабая связанность), общее удалённое приложение состояния (централизованное хранилище) или состояние, которым владеет хост и которое передаётся через свойства. Хост должен владеть единственным провайдером маршрутизатора — удалённые приложения никогда не должны создавать собственные. Чёткие контракты взаимодействия через интерфейсы TypeScript сохраняют независимость команд и обеспечивают действительно независимое развёртывание.