State stacks under federation: the same React Native app built twice
TanStack Query and Zustand rebuild the app Redux Toolkit and RTK Query just built; both work, and what separates them is what happens when independent teams stop coordinating.
Blog
Current series
All series19 parts · Ongoing · next part 17 AugIn progress
React Native Module Federation
Build a federated React Native app from scratch with Module Federation and Re.Pack: runtime remotes, the shared-singleton contract, and a host shell that owns navigation.
9 of 19 publishedStart with part 1Next part · 17 Aug
More series
5 parts
Hiring
Rethinking how to hire React Native engineers: redesigning the tech test, scoring fairly from graduate to senior, and take-homes candidates actually finish.
4 parts
RN Foundations
The groundwork for a solid React Native project: API mocking, tiered secure storage, end-to-end testing, and a feature-first structure.
2 parts
State Management
How to choose state management with a clear head: server state vs client state, cache-invalidation shapes that steer team habits, and what Module Federation changes about the question.
All posts
Browse by series Browse by tag
Client state across the seam: remotes that bring their own slices in React Native
A remote injects the slice it alone owns into the shared store, the contract carries the one action that crosses, and a write arrives as a prop; dispatch before the slice exists and the add vanishes in silence.
Who owns what: boundaries, teams and coupling in a federated React Native app
Who owns a boundary, a component, a data definition? Five tests for cutting a federated React Native app along team lines, and what moves each answer.
One shared store: server state across federated remotes in React Native
A remote and an installed package inject their endpoints into one host store and share one cache; get the sharing wrong and the screen hangs on a spinner that never resolves.
Tags vs query keys: a small API difference that changes how teams coordinate
RTK Query tags and TanStack Query keys look interchangeable in single-team code. At multi-team scale they change what fails when teams drift out of sync.
Server state and client state: why React apps need two libraries
Server state and client state have different requirements. Why modern React stacks split the job between two libraries instead of one store.
The contract package: a versioned seam between federated remotes in React Native
No app can see what the others ship. Two packages, published and installed by version (a typed contract and the shared detail screen), give every side one definition and let semver govern drift.
The host shell: federated remotes as tabs in React Native
Turn the host from a single screen into a real app shell: it owns the tab bar and navigation, and each tab is a remote built, shipped and loaded on its own.
The shared-singleton contract in React Native Module Federation
Share react, react-native and a native library across a host and its remote the right way; getting it wrong crashes the app on launch, not quietly.
Your first federated remote in React Native
Two React Native apps, one loading the other's screen at runtime over Module Federation 2.0 with Re.Pack. Every step copy-paste, ending in a running app.
Why Module Federation in React Native
What runtime micro-apps buy a React Native app, what they cost, and when the trade is worth it. Intro to a series that builds a federated setup from scratch.
Why I use feature-first project structure in React Native
An argument for organising React Native projects by feature, not by type. The delete test, import boundaries, where shared code lives.
Get new posts by email
Engineering leadership, React Native, and building teams — in your inbox when something new goes live. No spam.
Double opt-in. Unsubscribe any time. · Privacy
Something went wrong. Please try again in a moment.
Almost there — check your inbox to confirm your subscription.