Serye · 20 bahagi · Isinusulat pa
React Native Module Federation
Bumuo ng federated React Native app mula sa simula gamit ang Module Federation at Re.Pack: runtime remotes, ang shared-singleton contract, at host shell na may hawak ng navigation.
5 sa 20 nai-publish na Susunod na part · Hulyo 20, 2026
- Bakit Module Federation sa React Native Ano ang ibinibigay ng runtime micro-apps sa React Native app, ano ang halaga nito, at kailan sulit ang palitan. Panimula sa series na bubuo ng federated setup.
- Ang iyong unang federated remote sa React Native Dalawang React Native app, isa naglo-load ng screen ng isa pa sa runtime sa Module Federation 2.0 at Re.Pack. Bawat hakbang copy-paste, tapos tumatakbong app.
- Ang shared-singleton contract sa React Native Module Federation I-share ang react, react-native at isang native library sa host at remote nito nang tama; ang maling paggawa ay nagpapa-crash sa app sa launch, hindi tahimik.
- Ang host shell: mga federated remote bilang tabs sa React Native Gawing tunay na app shell ang host: ito ang may-ari ng tab bar at navigation, at bawat tab ay remote na binuo, na-ship at nilo-load nang mag-isa.
- Ang contract package: isang versioned na tahi sa pagitan ng mga federated remote sa React Native Hindi nakikita ng host ang inilalantad ng remote. Isang contract package, na-install by version, ang nagbibigay ng isang depinisyon; semver ang bahala sa drift.
- Isang shared store: server state sa mga federated remote sa React Native
- Client state sa kabila ng tahi: mga remote na may dalang sariling slice sa React Native
- Mga state stack sa ilalim ng federation: ang parehong React Native app na binuo nang dalawang beses
- Dalawang backend, isang client? RTK Query vs Apollo sa React Native
- Ang design system bilang federated singleton sa 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