State changes when no reducer perform changes

[BrainCrumbz]

Hi all. Not sure if the title conveys its intended meaning, please bear with us.

In a plain redux app (without redux-toolkit), when you dispatch an action and no reducer acts on that, then no change of state is notified. See console logs in this stackblitz. (Dependencies: redux 4.2.0)

In a redux-toolkit app, in the same scenario, state changes are notified upon any dispatch, even if the state is not really changed. See console logs in this stackblitz. (Dependencies: @reduxjs/toolkit 1.9.0)

Of course, it does not make sense to dispatch an action not mapped in any reducer. But this could simulate the case where a reducer maps on an action, but then no real state change is made.

Is this behaviour intended? Does it cause any harm, e.g. to performance?

Just to give some context: we are working on a custom store enhancer, which adds some info to the store, and at some point we were noticing state change notification even when nothing was really changing. So we started wondering whether it was our enhancer or what.

Also, please point us in the right direction if this is not the right place for this topic.
Thanks all

[markerikson]

Can you clarify what those two examples are trying to show? They appear to be very different setups.

For the record, the core Redux store always runs all subscriber callbacks (ie calls to store.subscribe(callback)) after every action, regardless of whether the state was updated or not. RTK just ends up using createStore internally, so there is no difference in behavior between "vanilla Redux" and "RTK" here.

[markerikson]

Ah, interesting! Haven't seen anyone try that in a while.

[BrainCrumbz]

Yeah, it's somehow like "ok, now's their turn. Let's see what happens" :)

One PoC we'll make is centered around the "user interaction token". There's a better term for that and you will already know it, but my google-skills are failing me now. It's that feature for which some browser APIs are allowed only when called strictly within a user event handler. Some multimedia APIs fall under this category.

So, for example's sake, say that HTMLMediaElement.play() or HTMLMediaElement.load() is one of those, and this is considered as a side-effect called in some listener. If side-effect listens to actions, we have:

UI event handler -> dispatch -> reducer -> listener middleware (or other) -> action listener -> htmlMediaElem.play()

If side-effect listens to commands put in place by our new enhancer (with its meta-reducer and the logic to invoke registered listeners), we have:

UI event handler -> dispatch -> reducer -> our custom enhancer -> command listener -> htmlMediaElem.play()

In any case, for this to work, the whole chain must be called without returning control from the UI event handler to the runtime. If e.g. our enhancer calls command listeners asynchronously, after resolving some promise, this should not work.

[BrainCrumbz]

Hi there. Just for completeness: PoC with our custom enhancer works, i.e. the call chain is synchronous all the way down to command listener. We'd expect the same happens with middleware enhancer, in case we'd decide to use it.

[markerikson]

I'd be interested in seeing an example app and the actual enhancer implementation if you get a chance!

[BrainCrumbz]

Cool! You should have received an invitation to a private repo.