Add an action listener callback middleware

[markerikson]

Thunks are easy to use and a good default, but the biggest weakness is that they don't let you respond to dispatched actions. Sagas and observables are very powerful (too powerful for most apps), but they do let you kick off additional logic in response to actions.

I've been considering adding some kind of middleware that would be in between - something that lets you run callback functions in response to specific actions, but without the complex overhead of sagas and observables.

I have links to a bunch of existing middleware under the Middleware and Middleware - Async sections of my addons list. One of those might do what we need, or we can take inspiration.

Glitch appears to have one at handler-middleware.js , which maybe @modernserf could say something about.

[modernserf]

This is how I described this approach to my coworkers:

---

There are essentially two schools of thought for working with side effects with redux.

The first approach is to put the side effects in the actions -- e.g. instead of dispatching a simple value, dispatch a promise, or a function that calls side effects. Middleware like redux-promise and redux-thunk intercept these non-value actions and run them.

The second approach is to put the side effects directly into the middleware -- the actions are always simple values, but the middleware listens to these actions, and can run side effects in response to them. This is the approach used by redux-saga and redux-loop; it's also how logging and metrics-reporting middleware work.

I prefer the second approach because it encourages you to keep the "how" with the state, and the "what" with the UI. However, the tools associated with this approach, particularly redux-saga, tend to have a pretty steep learning curve. The approach I'm using here is less expressive, but much closer to the complexity of redux-thunk.

[markerikson]

Yep, that's the idea I'm going for here.

One possible improvement I'd like to consider is adding and removing subscriptions at runtime. The likely approach would be dispatch(addActionListener(type, callback)).

[dpyzo0o]

What's the status now? It seems to me that the extraReducers can be used to respond to dispatched actions. Or are you working on something else?

[phryneas]

What's the status now? It seems to me that the extraReducers can be used to respond to dispatched actions. Or are you working on something else?

Keep in mind, these are still reducers and should not have any side-effects.

But yes, API-wise I guess it will go in a similar direction as extraReducers, but we have no definite design yet. Suggestions welcome.

[dpyzo0o]

@phryneas

Yes, what I mean is I can respond to dispatched actions to change state in different slices, which is sort of listening behavior. I have seen the listener pattern in easy-peasy, here is the doc. Maybe you will have some inspirations from it.

By the way, I do think it's a very important feature to be included in redux-toolkit.

[phryneas]

@phryneas

Yes, what I mean is I can respond to dispatched actions to change state in different slices, which is sort of listening behavior. I have seen the listener pattern in easy-peasy, here is the doc. Maybe you will have some inspirations from it.

By the way, I do think it's a very important feature to be included in redux-toolkit.

Yes, this is a feature to make this reducer to react to actions from a different slice/other action. I hope the current documentation reflects that. this part of the StyleGuide should also reflect that we encourage that pattern.

What this is not is a feature to trigger asynchronous actions (thunk-like) from anything. I just assumed you were talking about that, because this whole issue is about a middleware for asynchronous actions.

[dpyzo0o]

@phryneas I wasn't aware that this issue is about asynchronous actions. I think a listener pattern is all about do something when some action is dispatched, no matter it is a synchronous or asynchonous action. So if we have the listener pattern implemented, the extraReducers syntax is no longer needed.

[phryneas]

@phryneas I wasn't aware that this issue is about asynchronous actions. I think a listener pattern is all about do something when some action is dispatched, no matter it is a synchronous or asynchonous action. So if we have the listener pattern implemented, the extraReducers syntax is no longer needed.

No, because an asynchronous listener cannot change state. Only reducers do. These are completely different responsibilities.

An asynchronous listener could only dispatch actions that finally might lead to state change.

The distinction is:

• extraReducer: Hey, someone clicked button X? I'll change my state.
• asynchronous action listener: Hey someone clicked button X? I'll better start loading stuff from an API and later dispatch another action then.

[markerikson]

Yeah, per my original comment, the one missing use case with RTK atm is that there's no built-in way to kick off additional logic in response to dispatched actions. Sagas and observables let you do that, but they're both very heavyweight in terms of bundle size, complexity, and mental overhead.

Given that, I'd like to provide a much lighter way to let people run simple callbacks, probably with access to dispatch and getState like thunks or something.

[dpyzo0o]

Yeah, per my original comment, the one missing use case with RTK atm is that there's no built-in way to kick off additional logic in response to dispatched actions. Sagas and observables let you do that, but they're both very heavyweight in terms of bundle size, complexity, and mental overhead.

Given that, I'd like to provide a much lighter way to let people run simple callbacks, probably with access to dispatch and getState like thunks or something.

When(roughly) would we expect to see this feature?

[markerikson]

No concrete plans or timing atm. Like, it's a thing I want to do, but I'm focused on docs work right now. (Or, more accurately, I'm on business travel for the next few weeks, and don't have much time to do either docs or coding).

If someone would like to pitch in and help work on this, I can help steer the work in the direction I'd like.

[phryneas]

If someone would like to pitch in and help work on this, I can help steer the work in the direction I'd like.

You know the drill, give me a direction and I'll try some things out ;)

The question is: do you want to do this

• as a separate createActionListenerMiddleware?
• Or as a map object to configureStore?
• Or a map object on createSlice (which I think would be appealing, but people would have to manually add all those middlewares in configureStore unless we added some magic slices argument to configureStore that combined rootReducer and middlewares - or some dev mode runtime checks if a slice reducer is used without it's middleware).