Generic on.update functionality about freezer HOT 4 CLOSED

HI @mehdi-cit

That is related to the not-implemented-feature transactions

#2

Currently, update event is only triggered once per tick so, even without the transaction, your code would trigger just one event in the store.

I don't think that creating a changeList of the paramenter of the event listener is a good idea, instead of that the listener receive the whole new store data.

The purpose of the library is to forget of what properties have changed and only listen to any change for re-rendering completely.It is easier to manage the apps that work that way than cherry picking the changes to update only the affected parts, that's why the event listeners receive the new data.

from freezer.

Thanks for the prompt reply arqex!

Are you suggesting that React's diffing would ensure that the process is efficient (fast rendering)?
I actually was contemplating the usage of freezer in a different setup (no React). But I guess freezer is really meant to be used with React and equivalent!

from freezer.

Yes, freezer is thought to be used refreshing the whole UI on every change, it makes react (or equivalent) faster because you can check when a subtree should be updated just with a simple comparison

var doUpdate = ( newData.foo != oldData.foo );

Since data properties are immutable, if newData.foo == oldData.foo you feel sure that the node doesn't need to be updated, no matter how deep is the data that newData.foo contains.

If you want to control exactly what to update in your UI based on the changes in your store, maybe you should have a look at

https://github.com/mquan/cortex

or

https://github.com/Yomguithereal/baobab

from freezer.

Thanks for confirming my assumptions.
Indeed cortex author has just (18 days ago) implemented the sought after feature:
mquan/cortex#52
I don't know how I missed that.

from freezer.