MobX为何需要actions？为何不通过setImmediate批量处理所有变更？

Great question—this gets right to the heart of how MobX balances reactivity, control, and user experience. Let’s unpack this step by step.

First: Why setImmediate Isn’t a Replacement for Actions #

While setImmediate could technically batch state changes into the next event loop, it misses several key benefits that MobX’s actions provide:

• Granular control over batching: setImmediate would batch all synchronous state changes into a single next-loop update, but sometimes you need to split updates into separate batches. For example, if you want to update two parts of state and trigger a reaction after the first update (before the second), setImmediate can’t do that. Actions let you define explicit boundaries—you can nest actions, split them into separate functions, or even opt out of batching for specific changes when needed.

• Readability and debuggability: Actions act as clear markers for "state-modifying code." When you see @action or action(), you immediately know this function changes state. With implicit setImmediate batching, you’d have no way to glance at code and identify where state updates happen, making debugging and onboarding harder.

• No unnecessary delay: setImmediate pushes all state changes to the next event loop, which introduces a small but noticeable lag between state updates and reactivity triggers. For real-time interactions (like form validation or live UI previews), this delay can hurt user experience. MobX’s action batching happens immediately after the current synchronous execution flow ends—no extra event loop hop required.

• Compatibility and reliability: setImmediate isn’t supported in all environments (e.g., older browsers or some JS runtimes). MobX’s action system is pure JavaScript, so it works everywhere. Additionally, setImmediate mixes your state updates with other pending async tasks, which can lead to unpredictable ordering of reactions. MobX’s internal batching prioritizes state reactivity over other async work, keeping your app behavior consistent.

Second: Advantages of Triggering Observers Immediately After Actions #

Triggering observers right after an action finishes (instead of waiting for the next event loop) offers three key benefits:

• Instant user feedback: Imagine typing into a form where the UI validates your input in real time. If reactions waited for the next event loop, there’d be a tiny but visible delay between typing and seeing the validation message. Immediate triggers make interactions feel snappy and responsive.

• Consistent state in synchronous code: If you run code right after an action (e.g., calling a function that depends on the updated state), immediate reactivity ensures that function sees the latest state values. With setImmediate, that function would still see the old state until the next loop, leading to bugs and inconsistent behavior.

• Avoiding intermediate state flashes: When you make multiple state changes in a single action, triggering observers once after all changes are done ensures they only see the final state. If you waited for the next loop (or didn’t batch at all), observers might react to intermediate states, causing UI flickering or incorrect temporary states. For example, updating both a "loading" flag and data in one action—you don’t want the UI to show "loading" and then immediately switch to the data; you want it to jump straight from the previous state to the loaded state.

Wrap-Up #

Actions aren’t just about batching—they’re about giving you control, clarity, and predictability over how state changes happen. While setImmediate can mimic part of their behavior, it sacrifices the granularity, speed, and reliability that make MobX’s reactivity model so effective.

内容的提问来源于stack exchange，提问作者Vasilii Rogin