New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reducers and action creators aren't a one-to-one mapping #8

Closed
gaearon opened this Issue Jan 1, 2016 · 4 comments

Comments

Projects
None yet
3 participants
@gaearon

gaearon commented Jan 1, 2016

This part of README worries me a lot:

Reduxible provides some utility functions to make redux actions and reducer simpler. You can define actions like below.

const actions = {
  ADD_TODO: {
    creator: (todo) => {
      return {
        payload : {
          todo
        }
      };
    },
    reducer: (payload, state) => {
      const { todo } = payload;
      const todos = [ ...state.todos, todo ];
      return {
        todos
      };
    }
  }
};

It reinforces a very common misconception about Redux: namely that action creators and reducers are one-to-one mapping.

This is only true in trivial examples, but it is extremely limiting in real applications. Beginners exposed to this pattern couple reducers and action creators, and fail to realize they're meant to be many-to-many and decoupled.

Many reducers may handle one action. One reducer may handle many actions. Putting them together negates many benefits of how Flux and Redux application scale. This leads to code bloat and unnecessary coupling. You lose the flexibility of reacting to the same action from different places, and your action creators start to act like “setters”, coupled to a specific state shape, thus coupling the components to it as well.

I suggest you to refrain recommending this approach, or at least add a warning that Redux doesn't endorse it.

@hnordt

This comment has been minimized.

Show comment
Hide comment
@hnordt

hnordt Jan 1, 2016

Or maybe provide it as a simple helper for reducers and actions that are really coupled, still adding a warning about it of course.

hnordt commented Jan 1, 2016

Or maybe provide it as a simple helper for reducers and actions that are really coupled, still adding a warning about it of course.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jan 1, 2016

As soon as you have such helper used in a codebase new people start to structure their code in similar ways because they think that's how it should be done.

The point of Flux and Redux is to make it easy to suddenly start reacting to the same action in a different place. You don't know which actions you'll need to handle in different places in advance.

One needs to look at the code not just from "how it looks now" perspective but also "how will it evolve" and "how can we reduce risks when requirements change". This pattern locks you into a very particular way of doing things. When you'll get more requirements you'll have to rewrite the part that used this helper anyway. This is why I consider providing such helper harmful, even if it seems to make code simpler in some cases. Requirements change!

gaearon commented Jan 1, 2016

As soon as you have such helper used in a codebase new people start to structure their code in similar ways because they think that's how it should be done.

The point of Flux and Redux is to make it easy to suddenly start reacting to the same action in a different place. You don't know which actions you'll need to handle in different places in advance.

One needs to look at the code not just from "how it looks now" perspective but also "how will it evolve" and "how can we reduce risks when requirements change". This pattern locks you into a very particular way of doing things. When you'll get more requirements you'll have to rewrite the part that used this helper anyway. This is why I consider providing such helper harmful, even if it seems to make code simpler in some cases. Requirements change!

@pitzcarraldo

This comment has been minimized.

Show comment
Hide comment
@pitzcarraldo

pitzcarraldo Jan 2, 2016

Owner

Hi, @gaearon :)
I'm so glad to your feedback. Reduxible started for my personal toy project for studying React, Flux, Redux. So it can have many holes. The feedback like this is very helpful for me and for Reduxible.

You're correct. I have tried to make redux modules (what called by ducks in here.) look good. To me, redux modules in there, so verbose and has too many repeats of action names. I want to make it short and simpler. But I missed a point of relations between action creator and reducer.

I have added some warning messages to README.md. And also, I'll try to fix functions for fit with basic concepts for Flux and Redux.

Thanks again @gaearon.
And Happy new year 😄

Owner

pitzcarraldo commented Jan 2, 2016

Hi, @gaearon :)
I'm so glad to your feedback. Reduxible started for my personal toy project for studying React, Flux, Redux. So it can have many holes. The feedback like this is very helpful for me and for Reduxible.

You're correct. I have tried to make redux modules (what called by ducks in here.) look good. To me, redux modules in there, so verbose and has too many repeats of action names. I want to make it short and simpler. But I missed a point of relations between action creator and reducer.

I have added some warning messages to README.md. And also, I'll try to fix functions for fit with basic concepts for Flux and Redux.

Thanks again @gaearon.
And Happy new year 😄

@pitzcarraldo

This comment has been minimized.

Show comment
Hide comment
@pitzcarraldo

pitzcarraldo Jan 5, 2016

Owner

Have added warning messages and refactor functions for support M:N relationship.

Owner

pitzcarraldo commented Jan 5, 2016

Have added warning messages and refactor functions for support M:N relationship.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment