Playing around with a reducer's syntax

[dariocravero]

Hi all,

After seeing a very common patter arise by using switch statements, I got thinking if there would be another way of structuring a reducer's internals apart from creating a custom middleware for it as suggested in the docs and I got to this.

I'm still sticking to the switch version because I'm failing to see any improvements from the the other patterns, however, before throwing it away I thought I'd share and see if others see any values in them? :)

(In all cases the specific reducers could be extracted into their own files but I reckon that most times they would be small enough to be kept within one reducer file anyway.)

Would love to hear your thoughts on this.

Thanks,
Darío

[asaf]

I like this style,

I guess this is the answer: https://github.com/gaearon/redux#but-there-are-switch-statements

One of the things that differentiates this project from other projects that attracted me from the first place is that it follows Minimal API Surface , It is summarized in the FAQ: (and I hope it'll be kept that way):

Fancy stuff like generating stores from handler maps, or generating action creator constants, should be in userland. Redux has no opinion on how you do this in your project

But it's great to see that the community posts their own thoughts about different possible approaches :)

[dariocravero]

Hi @asaf, I totally agree that this should be in user land (I was referring to that style :) thanks for bringing the link in) and I'm with you on redux's API surface and I'm not planning for any of this to be included on it at all. It was just a few alternatives of implementation without a custom middleware that as I said, they might not be useful at all but thought I'd still share :).

[asaf]

Awesome :)
Since the project is so new, as time passes, more and more approaches and patterns will pop up from experience, since Redux does not dictate everything, it may be useful to open some section to collect some ideas.

@gaearon I'll use this thread to say thanks for the hard work, I finally found 1 flux impl that I can fully read without banging my head in the wall from drowning into layers of abstractions and "cool" magics.

[gaearon]

Hey thanks @asaf!

I'm definitely thrilled to see reusable reducers and reducer factories in user land! Let's share them in this thread.

Something I'm looking forward to after the conference is making a library for pagination reducers. Pagination is a common problem in Flux, and reducer is the right abstraction to make it reusable because it combines the state shape and how the actions handle it, but it doesn't have to be tied to particular actions. (Think a function that takes "action types" parameter and returns a reducer.)

[leoasis]

One thing that may be useful as a perf optimization (perhaps?) with the handlers syntax, would be that a reducer that is configured with some handlers for some actions now knows which actions it handles, and thus the final composed reducer can use that knowledge to avoid calling it at all if the action is not one that that particular reducer can handle, and default to just moving on with the next reducer that handles that action or returning that same state if there is none that does. This may be useful for apps that contain a lot of reducers and actions, or invoke a lot of dispatches.

Or perhaps it's just an over-optimization. Just throwing the idea out loud to see what you guys think :P

[gaearon]

@leoasis I have a proof of concept of this here: #176. It's a transducer.

[gaearon]

Closing as not a real issue.
It would be nice to document this pattern though.

#140