Local state, local stores, and when to reach for a runtime store.
Quick Reference
State location decisions:
Keep UI state in leaf components (default)
Lift state to parent when multiple children need it
Use a local store from createLocalStore for cross-cutting concerns in one bundle (theme, user, org)
Use a runtime store from defineStore for state more than one remote reads or changes
Never build a store with create or createStore from zustand; the store API in @prepared911/core/stores wraps it
Avoid:
Prop drilling through 3+ component layers (use a local store instead)
Subscribing to state only used in callbacks (read on-demand)
Local vs Global State
Keep local UI state in leaf components:
Lift state when multiple components need it:
When to use a local store:
State needed across many components (theme, user, org)
State should persist across navigation
Bundle-wide configuration
There is no contextual store. Do not create a store inside a provider and pass it through React context: state one component tree owns stays in useState or useReducer, and state one module mount owns uses useModuleState from @prepared911/core/mfe/react.
Local Stores
Use createLocalStore from @prepared911/core/stores/local for state one bundle (one remote or one shell) owns. Call it once at module scope. It generates a reactive hook and a getter per state key, and useStore for any other selector.
With selectors:
Do not import create or createStore from zustand to build a store. A value more than one remote reads or changes goes in a runtime store from defineStore in @prepared911/core/stores instead.
Avoiding Prop Drilling
Don't pass props through 3+ component layers:
When prop drilling is acceptable:
Props passed through 1-2 levels
Props specific to a feature/component tree
Props don't change frequently
Optimization Patterns
Defer State Reads
Don't subscribe to state only used in callbacks—read on-demand:
Lazy State Initialization
Pass a function to useState for expensive initial values: