Why this exists
This library is built for React applications that want MobX stores without pushing everything into one big state tree and without leaking business logic into components.
It gives you:
- clean UI components that mostly describe layout
- stores that own state and business logic
- scoped dependency injection for feature-level state
- relative stores for local ownership
- global stores for app-wide ownership
- parent lookup when a child component should reuse an ancestor relative store
- SSR, stream rendering, persistence and development support under the hood
- stable store methods and state access without hook dependency boilerplate in components
The core idea is simple: state and business logic live in stores, UI stays in components, and the manager creates only what is needed for the current part of the tree.
What makes it different
The package is opinionated in the useful places:
- it acts like scoped DI for feature-level state and logic
- it separates
global and relative store ownership - it lets child components reach ancestor stores through parent lookup
- it avoids keeping unnecessary store instances alive
- it lets stores compose with other stores without prop drilling
- it keeps methods and state on stores, so components do not need hook dependency gymnastics
- it works with Suspense, SSR, streams, persistence and React Native scenarios
If that model matches how your app is structured, the library becomes straightforward to use and scale.
Relative stores Belong to concrete components or subtrees and disappear with them.
Global stores Are created once per manager and reused anywhere in the app.
Parent lookup Lets child components reuse ancestor relative stores without inventing another global layer.
Store composition Local stores can use parent or global stores through getStore(...) without prop drilling through component layers.
Operational support Persistence, SSR, stream rendering, HMR and React Native are already in the conversation.
Why it actually helps
@lomray/react-mobx-manager is not just state management.
It helps solve several problems at once:
- scoped DI for a feature or subtree
- store-to-store composition without manual prop drilling
- local stores living next to the components that own them
- predictable lifecycle for screens, modals, and nested UI blocks
- stable methods, functions, and properties on stores without hook dependency noise in components
In practice:
- a screen gets its own store through
withStores - child components reuse that store through
parentStore(...) - local UI blocks can own their own stores and still access parent or global stores through
getStore(...) - truly global things like auth, current user, or settings live separately and are not duplicated
That is why the library is closer to a context and dependency manager for MobX applications than to just another MobX wrapper.
One of the biggest practical wins is simple: the store stays next to the feature instead of disappearing into a global junk drawer, while nested components can still reuse it through parentStore(...).
Read this first
