5

I've been using Flux first and Redux later for a very long time, and I do like them, and I see their benefits, but one question keeps popping in my mind is:

Why do we decouple actions and reducers and add extra indirections between the call that will express the intent of changing the state (action) and the actual way of changing the state (reducer), in such a way that is more difficult to provide static or runtime guaranties and error checking? Why not just use methods or functions that modify a state?

Methods or function will provide static guaranties (using Typescript or Flow) and runtime guaranties (method/function not found, etc), while an action not handled will raise no errors at all (either static or runtime), you'll just have to see that the expected behavior is not happening.

Let me exemplify it a little better with our Theoretical State Container (TSC):

  • It's super simple
  • Think of it as React Component's state interface (setState, this.state), without the rendering part.

So, the only thing you need is to trigger a re-render of your components when the state in our TSC changes and the possibility to change that state, which in our case will be plain methods that modify that state: fetchData , setError, setLoading, etc.

What I see is that the actions and the reducers are a decoupling of the dynamic or static dispatch of code, so instead of calling myStateContainer.doSomethingAndUpdateState(...) you call actions.doSomethingAndUpdateState(...), and you let the whole flux/redux machinery connect that action to the actual modification of the state. This whole thing also brings the necessity of thunks, sagas and other middleware to handle more complex actions, instead of using just regular javascript control flows.

The main problem is that this decoupling requires you to write a lot of stuff just to achieve that decoupling: - the interface of the action creator functions (arguments) - action types - action payloads - the shape of your state - how you update your state

Compare this to our theoretical state container (TSC): - the interface of your methods - the shape of your state - how you update your state

So what am I missing here? What are the benefits of this decoupling?

This is very similar to this other question: Redux actions/reducers vs. directly setting state

And let me explain why the most voted answer to that question does not answer either my or the original question: - Actions/Reducers let you ask the questions Who and How? this can be done with the our TSC, it's just an implementation detail and has nothing to do with actions/reducers themselves. - Actions/Reducers let you go back in time with your state: again this is a matter of implementation details of the state container and can be achieve with our TSC. - Etc: state change orders, middleware, and anything that is currently achieved with actions/reducers can be achieved with our TSC, it's just a matter of the implementation of it.

Thanks a lot! Fran

Community
  • 1
  • 1
franleplant
  • 629
  • 1
  • 7
  • 17

1 Answers1

2

One of the main reasons is that constraining state changes to be done via actions allows you to treat all state changes as depending only on the action and previous state, which simplifies thinking about what is going on in each action. The architecture "traps" any kind of interaction with the "real world" into the action creator functions. Therefore, state changes can be treated as transactions.

In your Theoretical State Container, state changes can happen unpredictably at any time and activate all kinds of side effects, which would make them much harder to reason about, and bugs much harder to find. The Flux architecture forces state changes to be treated as a stream of discrete transactions.

Another reason is to constrain the data flow in the code to happen in only one direction. If we allow arbitrary unconstrained state modifications, we might get state changes causing more state changes causing more state changes... This is why it is an anti-pattern to dispatch actions in a reducer. We want to know where each action is coming from instead of creating cascades of actions.

Flux was created to solve a problem at Facebook: When some interface code was triggered, that could lead to a cascade of nearly unpredictable side-effects each causing each other. The Flux architecture makes this impossible by making every state transition a transaction and data flow one-directional.

But if the boilerplate needed in order to do this bothers you, you might be happy to know that your "Theoretical State Container" more or less exists, although it's a bit more complicated than your example. It's called MobX.

By the way, I think you're being a bit too optimistic with the whole "it's an implementation detail" thing. I think if you tried to actually implement time-travel debugging for your Theoretical State Container, what you would end up with would actually be pretty similar to Redux.

Pedro Castilho
  • 10,174
  • 2
  • 28
  • 39
  • You can treat state changes as transactions in the TSC too, think React's `setState(oldState => newState)`, that can be treated transactionally too. My hypothesis is that tracking the calls of `setState` is the same as tracking actions being dispatched (in fact, `this.setState` is actually dispatching a function associated with the context `this`, so the resemblance is deeper). Then, the data flow is still in one direction: methods are the only thing that could change the state, and a state being changed will trigger a re render, which is pretty one way flow. – franleplant Apr 26 '17 at 20:24
  • The important thing is that my hypothesis and probably my question too is that, if can give you one way data flow, static type checking, transactional state changes, without adding the indirections that the actions and reducers require, what is bad thing about it? – franleplant Apr 26 '17 at 20:30
  • It's less scalable and leads to a more rigid architecture, as actions tend to become tightly bound with their effects, making refactoring more difficult. Decoupling the actions from the handlers allows the architecture to be more flexible, which is important when developing large apps with changing requirements (the original use case of Flow). For instance, when using Flow, making an action have effects on previously non-existent parts of state is trivial. But other than that, no problem, as demonstrated by the existence of MobX, which does almost exactly that. – Pedro Castilho Apr 26 '17 at 20:37
  • Redux (and Flux in general) were originally meant for large apps where the boilerplate is not an issue. (by the way, I'll add all this to my answer later) – Pedro Castilho Apr 26 '17 at 20:41
  • 1
    That is starting to make more sense. I still hypothesize that the TSC might not be that rigid and the situation is even better with static type checkers and that the decoupling of actions and reducers via untyped, unchecked dispatching might not be that versatile. Or that the differences are not that huge. In a sense it makes me remember about event pipelines in Backbone Marionette framework that reduced the coupling between modules but made failures more difficult to detect. I will definitely check more about MobX. Thanks a lot! – franleplant Apr 26 '17 at 21:08