Redux: "Refactoring Reducers" recipe shouldn't promote over-abstraction

[gaearon]

From https://redux.js.org/recipes/structuringreducers/refactoringreducersexample:

Now it's very clear what's happening in each case. We can also start to see some patterns emerging.

I'd argue the original code is clearest of all examples, and every next iteration makes it more complex due to giving names to every intermediate concept that doesn't really deserve a name. That's how people come to thinking Redux is complex.

I understand where the writer is coming from. But I don't think code like this should look like a recommendation. Maybe a less extreme version of this could be helpful but I think this form is giving the wrong impression.

[markerikson]

/me raises hand

Apparently I'm the guilty one here :)

The train of thought was to illustrate that:

• We really just have one big reducer function
• We can break that into smaller functions
• You can do more than just "slice reducers" - feel free to break out whatever functions you feel are appropriate along the way

In fairness, I _did_ write this at the top of the page:

this example is deliberately written in a verbose style in order to illustrate the concepts and the process of refactoring, rather than perfectly concise code.

[acusti]

For what it’s worth, I prefer the final result of that recipe to the starting example. I work on a very complex app that manages its state with redux, and our general pattern is to use an immutable.js-compatible combineReducers helper for slicing our state and separate functions for handling different actions that we call from the switch case. We don’t use a createReducer type helper because we largely don’t mind switch statements (except for their lack of block scope 😠), but I understand why people do.

I do, however, think that the “Extracting Utility Functions” isn’t particularly helpful and distracts from the goal of teaching common reducer patterns. It doesn’t help that it’s the very first step in the article. So I would say that removing that extra abstraction and verbiage could help avoid making everything look more complicated than it is.

And I personally would also remove the “Reducing Boilerplate” section, though I also get the justification for keeping it. A few thoughts: it comes before introducing combineReducers, and I would guess that in the wild, use of a combineReducers helper is more widespread than use of a createReducer-like helper; and it splits the “Separating Data Handling by Domain” section that introduces state slicing, from the “Combining reducers by slice” section that introduces the combineReducers helper. Most importantly, removing it means that the final example has one less new abstraction for readers to understand in order to grok the whole example.

[lstkz]

@gaearon
"Creating simple code in a complex way" :wink:

Designing software is a very subjective topic, and libraries should stay as neutral as possible. There are people who like such approach "split logic to many tiny functions", but other people don't like it because it's better to read the real code instead of function names.

See for example Jest. There are many books which describe best practices for testing, but you won't find any "receipts" in Jest. They just give you a tool and you can do whatever you want. The same should apply to Redux.

Redux docs are going definitely in the wrong direction. Documentation tries to describe literally everything: "integration with X library", "N ways to do Y", design problems etc. Also, there are tons of information that 99.999% users won't need like "Monkeypatching Dispatch".

Developers who started using redux 2-3 years ago probably don't need to check docs anymore, because they already have their own setup. New developers probably will have this problem.

[pdfrod]

Also, there are tons of information that 99.999% users won't need like "Monkeypatching Dispatch".

Very much this. I was reading that section today and found it very surprising that it was part of the tutorials. As a user I don't need to know how the dispatcher / middleware are implemented internally; I just need to know how to use them.

[markerikson]

@pdfrod : agreed. When we revamp the docs (soon, hopefully), I want to have one page that talks about how and why to use middleware in general, and another page that talks specifically about why middleware are implemented using that pattern.