Sèrie · 20 parts · En curs
React Native Module Federation
Construeix una app React Native federada des de zero amb Module Federation i Re.Pack: remots en temps d'execució, el contracte de singleton compartit i un host shell que controla la navegació.
5 de 20 publicats Propera part · 20 de juliol del 2026
- Per què Module Federation a React Native Què aporten les micro-apps en temps d'execució a una app React Native, què costen i quan val la pena. Intro a la sèrie que construeix un setup federat de zero.
- El teu primer remote federat a React Native Dues apps React Native, una carregant la pantalla de l'altra en execució amb Module Federation 2.0 i Re.Pack. Cada pas copia i enganxa, fins a l'app en marxa.
- El contracte de singletons compartits a React Native Module Federation Comparteix react, react-native i una llibreria nativa entre un host i el seu remote com cal; fer-ho malament fa petar l'app en arrencar, no en silenci.
- La closca del host: remotes federats com a pestanyes a React Native Converteix el host d'una sola pantalla en una closca d'app: té la tab bar i la navegació, i cada pestanya és un remote construït, desplegat i carregat a part.
- El paquet de contractes: una costura versionada entre remotes federats a React Native El host no veu què exposa un remote. Un paquet de contractes publicat i instal·lat per versió dona als dos costats una sola definició; semver governa la deriva.
- Un sol store compartit: estat de servidor entre remotes federats a React Native
- Estat de client a través de la costura: remotes que porten els seus propis slices a React Native
- Stacks d'estat sota federació: la mateixa app de React Native construïda dues vegades
- Dos backends, un sol client? RTK Query contra Apollo a React Native
- El design system com a singleton federat a 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