React/MobX单Store与多Store选型及实践技术问询

Hey there! As someone who's navigated these exact questions when starting out with React and MobX, let's break down your concerns clearly—since you're still relatively new (3 months in is totally normal to have these doubts!), we'll focus on what makes sense for your specific project context.

1. Will a single Store lead to a testing disaster? #

Short answer: Not with your current project size.

Since your app's state isn't large and your code is highly customized, testing a single AppState store is totally manageable with Jest. You can directly import the AppState class, instantiate it in your test files, and write tests for its methods and state changes—just make sure each method in AppState has a single, clear responsibility.

For example, if you have a method that updates a data visualization filter, your test can create an instance of AppState, call the method, and assert that the filter state changed correctly. The only time a single store becomes a testing headache is when it grows into a "god object" with dozens of unrelated methods and state properties—something you don't have to worry about right now.

2. Can I use rfx-core with a RootStore (multi-store setup)? #

Absolutely! The code snippet you proposed works just fine with rfx-core:

import { store } from "rfx-core";
import RootStore from "./RootStore";
export default store.setup({ rootStore: RootStore });

Your RootStore can still initialize child stores by passing a reference to itself, so child stores can communicate with each other if needed:

class RootStore {
  constructor() {
    this.userStore = new UserStore(this);
    this.todoStore = new TodoStore(this);
  }
}

You don't need to implement a singleton pattern manually—rfx-core handles managing the store instance for you. This setup lets you split your state into logical groups while keeping everything tied together under a root store.

3. Is there a significant advantage to using multi-stores right now? #

Based on your description—probably not.

MobX's recommendation to split UI and domain state makes sense for apps where domain logic can be reused (e.g., a user authentication store that works across multiple apps). But your project is highly customized, state is small, and you don't have a need for reusable domain logic.

Switching to multi-stores right now would add unnecessary complexity: you'd have to handle communication between stores (via the root store or MobX reactions) and add extra boilerplate to inject stores into components. For your current needs, keeping things simple with a single store is the better call.

4. Will a single store slow down my app? Does multi-store improve speed? #

Performance-wise, there's almost no difference between the two setups.

MobX's reactivity system tracks exactly which components depend on which state properties. Whether those properties live in a single store or split across multiple stores, only the components that use the changed state will re-render.

A single store won't slow you down unless you're organizing state in a way that forces components to observe unrelated properties (e.g., a component watching the entire store instead of specific fields). As long as you're using @observer correctly and accessing only the state your component needs, performance will be identical between single and multi-store setups.

5. Does injecting a RootStore add unnecessary complexity? #

Yes, in your case it does.

The pattern you showed where you extract child stores from the root store in the component constructor adds extra steps compared to injecting a single appState directly. While you can simplify it by using a custom inject function:

@inject(stores => ({
  userStore: stores.rootStore.userStore,
  uiStore: stores.rootStore.uiStore
}))
@observer
export default class MyComponent extends React.Component {
  // Now you can use this.props.userStore directly
  render() {
    return <div>some stuff</div>;
  }
}

This is still more boilerplate than just injecting your single appState store. For a small app with no need for store separation, this is extra work without meaningful benefit.

Final Recommendation #

Stick with your single AppState store for now. It's simpler, fits your project's small state size, and won't hinder testing or performance. If your app grows significantly in the future—say, you add reusable domain logic or the store becomes too bloated—you can always refactor to a multi-store setup later.

内容的提问来源于stack exchange，提问作者Dunkee Funk