Compartilhando estado e roteamento entre remotos

Cada aplicação remota do Module Federation é compilada e implantada de forma independente. Seu estado (React useState, Contexto e lojas Zustand) fica no próprio escopo do módulo JavaScript. A aplicação principal e as aplicações remotas não compartilham o estado automaticamente — você precisa projetar esse compartilhamento de forma explícita.

O mecanismo mais simples de compartilhamento de estado é a URL: qualquer aplicação remota pode ler parâmetros da URL, cadeias de consulta e valores de hash sem nenhuma comunicação entre aplicações remotas. Isso funciona bem para o estado da navegação principal, valores de filtros e qualquer estado que deva poder ser salvo nos favoritos e compartilhado por meio de um link.

CustomEvents, por meio do EventTarget do navegador, permitem que as aplicações remotas se comuniquem sem importações diretas. Uma aplicação remota executa window.dispatchEvent(new CustomEvent('cart:updated', { detail: cart })), e qualquer outro módulo (a aplicação principal ou outra aplicação remota) escuta usando window.addEventListener('cart:updated', handler). Não é necessário um módulo compartilhado.

Crie uma aplicação remota de estado dedicada que exponha uma loja Zustand ou Jotai. Tanto a aplicação principal quanto as outras aplicações remotas importam dessa aplicação remota de estado e obtêm a mesma instância da loja, pois ela é uma instância única compartilhada. Essa abordagem é poderosa para estados compartilhados complexos (autenticação, carrinho e preferências do usuário), mas acrescenta uma dependência de implantação.

A aplicação principal controla todo o estado compartilhado e o transmite às aplicações remotas como propriedades ou por meio do Contexto. As aplicações remotas recebem funções de retorno, como onCartUpdate, e navegam usando propriedades. Isso mantém o estado centralizado na aplicação principal, mas exige que ela conheça as APIs das aplicações remotas, criando um acoplamento rígido.

O histórico e o estado da localização do React Router são fornecidos por um componente de roteamento (BrowserRouter ou createBrowserRouter). Deve haver exatamente um componente de roteamento em uma configuração do Module Federation — colocá-lo em cada aplicação remota criaria vários contextos de roteamento concorrentes, causando conflitos de navegação.

A regra arquitetural é: a aplicação principal fornece o componente de roteamento. As aplicações remotas recebem propriedades de roteamento da aplicação principal (ou leem diretamente da URL). Uma aplicação remota nunca deve criar seu próprio BrowserRouter — isso entraria em conflito com o componente de roteamento da aplicação principal e interromperia a navegação de toda a aplicação.

Os valores do Contexto do React estão vinculados a uma instância específica do React e a um objeto de Contexto específico. Para que um Contexto funcione entre a aplicação principal e uma aplicação remota, ambas precisam importar o mesmo objeto de Contexto da mesma origem — normalmente da aplicação remota de estado compartilhado ou de um pacote compartilhado de utilitários. A instância única do React garante que o mesmo Contexto funcione em todas as aplicações remotas.

Em uma arquitetura limpa do Module Federation, a aplicação principal controla: a estrutura HTML principal, o provedor de roteamento, o contexto de autenticação, o provedor de tema e tokens visuais e a navegação global. As aplicações remotas controlam o conteúdo de seus próprios domínios funcionais. A aplicação principal reúne as aplicações remotas no layout sem conhecer os detalhes de sua implementação.

O maior padrão inadequado do Module Federation é o acoplamento rígido entre a aplicação principal e as aplicações remotas: a aplicação principal importa tipos da aplicação remota, a aplicação remota importa componentes da aplicação principal ou ambas compartilham um pacote npm comum que precisa ser atualizado simultaneamente. Esses acoplamentos anulam o propósito da implantação independente.

Defina contratos explícitos entre a aplicação principal e as aplicações remotas: as propriedades aceitas por um componente remoto, os CustomEvents que ele dispara e os parâmetros da URL que ele lê. Documente esses contratos como interfaces do TypeScript em um pacote compartilhado de tipos. Isso permite que as equipes evoluam de forma independente dentro do contrato acordado.

Onde o provedor do React Router (BrowserRouter) deve ser colocado em uma arquitetura do Module Federation?

O compartilhamento de estado entre aplicações remotas do Module Federation pode usar estado na URL (a opção mais simples), CustomEvents (baixo acoplamento), uma aplicação remota de estado compartilhado (loja centralizada) ou estado controlado pela aplicação principal e passado como propriedades. A aplicação principal deve controlar o único provedor de roteamento — as aplicações remotas nunca devem criar o próprio. Contratos claros de comunicação por meio de interfaces do TypeScript mantêm as equipes desacopladas e possibilitam uma verdadeira implantação independente.