Forbid dispatch from inside a reducer

[gaearon]

We should throw if you attempt to dispatch while the reducer is being called.

Note that this will not cause the dreaded Cannot dispatch in a middle of dispatch if you dispatch from component's componentDidMount or componentWillReceiveProps. Unlike Flux, we don't have this problem, because we call all subscribers after the reducer is called.

This means we can set a flag immediately before currentState = reducer(currentState, action) in createStore and reset it on the next line, so everything happens before the subscribers are called. The subscribers should be able to call dispatch just fine.

I'd very much like to see this as a PR as I don't have much time. It needs to:

• Introduce the error if you dispatch while the reducer is evaluating.
• Include a test for this.
• Should not fail the existing “should handle nested dispatches gracefully” test

Please build it on top of breaking-changes-1.0 branch.

[gaearon]

Another note: need another test to check that an error inside a reducer resets the flag back, i.e. there should be try/finally in the implementation to reset the flag.

[knowbody]

I'm on it @gaearon

[phated]

@gaearon what is the reason for adding this? I've disliked it in every Flux implementation that has it, and not just because the lifecycle issues.

[gaearon]

@phated Simply because this is never a valid use case. Reducers must be pure.

[gaearon]

In Flux there are valid-ish situations when you'd rather wish this check didn't exist, but in Redux there's just no excuse for dispatching inside reducer. It's never the right solution, and it only indicates a problem in the code.

[phated]

Can't it be implemented as middleware and be opt-in or opt-out. Having explicit throws that you can't turn off in library code is a pain.

[jide]

For complicated edge cases there are middlewares.

[phated]

Maybe it should just be a warning then?

[gaearon]

If it's a middleware, I doubt anybody who'd be affected by the error (beginners) would know to use it.
Why would you want to dispatch inside a reducer? It's grossly misusing the library.
It's exactly the same as React doesn't allow you to setState inside render.

[gaearon]

In fact a custom middleware can opt you “out” of this behavior by queueing the “bad” dispatch on a next tick. But I still can't envision a scenario where you'd need it.

[phated]

I've been thinking about API design a lot lately and I've come to determine that authors can't see all use cases that consumers will do, so I think avoiding things that completely break them (like throwing) should be avoided. I agree that it is incorrect usage, so I think there should be a friendly warning (like React's dev warnings) but not an explicit throw.

[gaearon]

Generally I agree with your statement. It's a tricky line. For example, Redux doesn't try to enforce that you don't mutate the state. Mutating is the wrong thing to do and is a common source of mistakes, but we recognize that people sometimes might have valid reasons to mutate. We might warn them in the future, we might offer opt-in freeze-all-state plugins, but we won't disallow it.

However there are some fundamental assumptions a library can make too. In case of Redux, it's a fundamental assumption that reducers don't cause side effects. You can always trivially have an upgrade path by moving this dispatch call into an action creator. It's not like we're getting in somebody's way.

As you said, React has dev warnings, it's true. But if you try to setState from render it will throw hard. Precisely because “render doesn't have side effects” is a fundamental assumption React makes, and if you're not following it, you can't write a correct React app.

Dispatching from inside a reducer is never correct because you'll overwrite the result of your first dispatch. It will be lost and unaccounted for, and will seem like a weird bug to the consumer. This is the reason it's better to throw and educate and offer an upgrade path, than to allow the wrong behavior.

[gaearon]

In other words, throwing will break them explicitly, but allowing to do that will break them implicitly.