onStateChange for no state changes

[Christian Pekeler]

The result of a reducer doesn't always change the state. Would it make sense to not trigger onStateChange in this case?

For a typical choo app, I'd imagine that a deep comparison of old state to new state for the keys returned by the reducer is faster than re-rendering everything.

[Yosh]

The result of a reducer doesn't always change the state

When would this be the case? Reducers are intended to change state; I feel catching this earlier might be more efficient than optimizing the update algorithm for unintended behavior. We warn in choo-log if an update is flushed that has no diffs, so we're already helping spot and prevent this

[Christian Pekeler]

Please correct me if I misunderstood the architecture. I assumed the bulk of my client side business logic is supposed to be in the model, i.e. runs in response to actions; and the action-sending side is supposed to be simpler. With this assumption, the action sending side can not know how the state is going to change, therefore it can't make the decision whether or nor to send the action.

Maybe I'm just mistaken after having read a bunch about Redux where the docs say (http://redux.js.org/docs/basics/Reducers.html):

Actions describe the fact that something happened, but don't specify how the application's state changes in response. This is the job of a reducer.

OK, some examples where an action doesn't always produce a different state:

• action: mouseMoved from onmousemove event with x and y coordinates, affected state: mouseIsMovingFast
• action: textEntered from oninput event with the textual value, affected state: autocompleteSuggestion
• action: textEntered debounced from oninput event with the textual value, affected state: text (user hit a key immediately followed by backspace)
• action: displayHelp from onkeydown event, affected state: showHelpPanel (user hit the "H" key twice and it's not a toggle)