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

[gaearon]

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]

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]

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]

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]

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

[ramiloif]

I'm building a chat app, but the data on the server has only messages list.
So is it ok to put CONTACTS and MESSAGES reducer to RECEIVE_MESSAGES action,
and each one will take his part?
Or you only talking about a UI actions?

[captainkovalsky]

look great, but need to connect more than one reducer to the action. I agree that this approach tide together action and reducer.