Serie · 20 partes · En curso
React Native Module Federation
Construye una app React Native federada desde cero con Module Federation y Re.Pack: remotes en tiempo de ejecución, el contrato de singleton compartido y un host shell que controla la navegación.
5 de 20 publicados Próxima parte · 20 de julio de 2026
- Por qué Module Federation en React Native Qué aportan a una app de React Native los micro-apps en runtime, qué cuestan y cuándo compensa. Intro de una serie que construye un setup federado desde cero.
- Tu primer remote federado en React Native Dos apps de React Native, una carga la pantalla de la otra en runtime con Module Federation 2.0 y Re.Pack. Cada paso se copia y pega, hasta una app en marcha.
- El contrato de singletons compartidos en React Native Module Federation Comparte react, react-native y una librería nativa entre un host y su remote de la forma correcta; hacerlo mal rompe la app al arrancar, no en silencio.
- La cáscara del host: remotes federados como pestañas en React Native El host pasa de una pantalla a cáscara de la app: es dueño de la tab bar y la navegación, y cada pestaña es un remote construido, desplegado y cargado aparte.
- El paquete de contratos: una costura versionada entre remotes federados en React Native El host no ve lo que expone un remote. Un paquete de contratos publicado e instalado por versión da a ambos lados una definición y semver gobierna la deriva.
- Un store compartido: estado de servidor entre remotes federados en React Native
- Estado de cliente a través de la costura: remotes que traen sus propios slices en React Native
- Stacks de estado bajo federación: la misma app de React Native construida dos veces
- ¿Dos backends, un cliente? RTK Query vs Apollo en React Native
- El sistema de diseño como singleton federado en React Native
- The design system as a federated singleton
- Accessibility testing across federated remotes
- shell.navigateTo: RN ↔ native handoff
- The production build and the three modes
- Loading remotes from a CDN + version resolution
- The live two-version flip
- Offline fallback baked into the binary
- In-session fallback when a remote fails
- Signing the version-map + replay/rollback guard
- Health-based cross-launch auto-rollback