Better state change checks & handling.

[n1k0]

Totally unsure about this one. This mostly wants to improve performances when state is updated often with the very same state values, to avoid unnecessary subscriber notifications.

I'm using JSON.stringify(state) comparison, because I don't want to go the JavaScript typechecks warpath, though that's probably limiting. That was a very bad idea. Back to standard strict check and basta. Someday we'll have builtin immutable structures, so we'll be able to safely compare things.

Needs feedback/review from @lionelB and/or anybody interested.

[coveralls]

Coverage decreased (-0.16%) to 98.57% when pulling fc2fa97 on better-state-change-handling into 4be2f82 on master.

[lionelB]

1 - do you encounter the problem ? if so provide benchmark about performance boost
2 - I think calling function handler and copy variable are lightweight than JSON.stringify,
3 - Let react handle update if needed

[n1k0]

1 - do you encounter the problem ?

Yes, that's why I made the PR tbh.

if so provide benchmark about performance boost

I tried using matcha but it's painfully broken with async benchmarks, wasted some hours on this yesterday evening, and using the setImmediate trick mentioned in the comments only brought more problems, so I decided not to bother with this.

2 - I think calling function handler and copy variable are lightweight than JSON.stringify,

Yeah, and as you can see latest version of the patch don't rely on serialization anymore, just strict equality check. I think that's a fairly decent compromise.

3 - Let react handle update if needed

That means implementing shouldComponentUpdate everywhere by hand; I really think stores could take care of basic checks like basic state identity change checks, to avoid users having to write too much boilerplate.

[lionelB]

thanks for the answer (and apologize because I rereading my comment and it sounds a bit imperative )
By the _ let react handle update _ I thought that react was smart enough to not update if state is not really updated and so no cause performance issues

[n1k0]

Landed along 0ed606a.