Don't fire update if the top-level state doesn't change after a reducer

[LPGhatguy]

This probably doesn't come up often in practice, but it seems like a fairly low-effort optimization for this case.

[OverHash]

By top-level state are you referring to not checking recursively? That would make more sense as checking recursively can be quite costly.

Part of this issue is optimization, but it heavily depends on what's happening inside the .changed, for instance, if users manually check to see if the value they want has actually changed, this issue doesn't affect them (and would actually slow their code down), but otherwise, it could make a slight performance gain.

[ZoteTheMighty]

If I understand correctly, the only time that this will be an improvement is if we're using the store and thunks to to trigger a side effect without actually changing any state, right? That seems too infrequent to be a concern, especially since lots of thunks will also dispatch more changes that do change the state before the next flush anyways.