Reducer Composition with Effects in JavaScript

[gaearon]

Inspired by this little tweetstorm.

Problem: Side Effects and Composition

We discussed effects in Redux for ages here but this is the first time I think I see a sensible solution. Alas, it depends on a language feature that I personally won’t even hope to see in ES. But would that be a treat.

Here’s the deal. Redux Thunk and Redux Saga are relatively easy to use and have different pros and cons but neither of them composes well. What I mean by that is they both need to be “at the top” in order to work.

This is the big problem with middleware. When you compose independent apps into a single app, neither of them is “at the top”. This is where the today’s Redux paradigm breaks down—we don’t have a good way of composing side effects of independent “subapplications”.

However, this problem has been solved before! If we had a fractal solution like Elm Architecture for side effects, this would not be an issue. Redux Loop implements Elm Architecture and composes well but my opinion its API is a bit too awkward to do in JavaScript to become first-class in Redux. Mostly because it forces you to jump through the hoops to compose reducers instead of just calling functions. If a solution doesn’t work with vanilla combineReducers(), it won’t get into Redux core.

Solution: Algebraic Effects in JavaScript

I think that what @sebmarkbage suggested in this Algebraic Effects proposal is exactly what would solve this problem for us.

If reducers could “throw” effects to the handlers up the stack (in this case, Redux store) and then continue from they left off, we would be able to implement Elm Architecture a la Redux Loop without the awkwardness.

We’d be able to use vanilla combineReducers(), or really, any kind of today’s reducer composition, without worrying about “losing” effects in the middle because a parent didn’t explicitly pass them up. We also would not need to turn every reducer into a generator or something like that. We can keep the simplicity of just calling functions but get the benefits of declaratively yielding the effects for the store (or other reducers! i.e. batch()) to interpret.

I don’t see any solution that is as elegant and simple as this.

It’s 2am where I live so I’m not going to put up any code samples today but you can read through the proposal, combine it with Redux Loop, and get something that I think is truly great.

Of course I don’t hold my breath for that proposal to actually get into ES but.. let’s say we could really use this feature and Redux is one of the most popular JavaScript libraries this year so maybe it’s not such a crazy feature as one might think at first 😄 .

---

cc people who contributed to relevant past discussions: @lukewestby @acdlite @yelouafi @threepointone @slorber @ccorcos

[evenstensberg]

I'd love this with a twist. Having the previous state to automatically go into an array through object.Assign/other invoke methods and maybe have them to be pure reducers/actions if you want them to based upon needs. Say you have a() -> 5 and b -> 7 and want c = a() + b(); ... If you want to use a later, you can reference the function as Sebastian proposed and later use it in another call by doing it from the array of yields. Sorry for explaining this very. Badly and with no code highlighting. 4 am and writing this at my iPad, will clarify tomorrow if needed

[gaearon]

Not sure what you mean, code would definitely help 😄 . I’ll try to put up some examples too when I find some time.

[lukewestby]

Agreed on the awkwardness of composing Effects in middle reducers. The Elm compiler plays a huge role in making it doable with elm-effects. We've already begun to experiment with algebraic effects at Raise by co-opting generators to yield effects or yield spawn() other generators. I think it's about as close an approximation as we've been able to come up with without inventing syntax and writing a babel plugin. I really like @sebmarkbage's point about not needing three different execution style notations for async vs generator vs plain, and we've approximated that by just saying everything is a generator because anything might want to yield an effect at some point. We've been successful so far using it for request handlers in Node, but I'm not really sure how it would look when combined with redux-loop. I think this might be more of an evolution from redux-loop than a combination with it, what do y'all think?

[acjay]

Interesting! So would there be a new concept of effect handlers?

Related reading: http://blog.paralleluniverse.co/2015/08/07/scoped-continuations/

Redux-loop seems to basically be the monadic idea. A reducer in that sense is the argument to flatMap. The delimited continuation model seems similar to that author's scoped continuations.

One thing that seems weird is the use of continuations. Is it too much power to have values injected back into the continuation? Maybe it's just grating against my Redux guide training, but suddenly it seems like reducers are going to get a lot more complicated, with fetching happening in-line. But I suppose that complexity has to live somewhere.

Another thought: with monadic style, you can test each phase independently, but you kind of lose that ability if you have one long thread of control.

I haven't ever tried to compose separate Redux-based components, so my thoughts are all from the perspective of a monolith. More thoughts on how this would make Redux apps more composable would be helpful, to me at least.

[eloytoro]

Hasn't anyone considered using something such as co to simulate an "effect like" operation? It looks like it could fill the current void for an effect syntax

[acjay]

I use co, but I'm not sure what you mean. It's basically just an option for getting async/await with generators. From the use I'm familiar with, it's not so much an effect executor as a way to work with promises. You still have to fire off the effect yourself, which is impure. In other words, you want to be able to yield some value that an effect handler will use to trigger a fetch, and inject the returned value back. But with co, you'd execute the fetch yourself and yield the resulting promise to resolve it. That's not decoupled in the same way.