Trigger event on child nodes? about freezer HOT 6 CLOSED

HI @rahatarmanahmed

You can trigger events in the listeners of child nodes.

var store = new Freezer({a: {b: [1,2,3]}}),
  listener = store.get().a.b.getListener()
;

listener.on('sayHi', () => console.log('Hi!'));
listener.trigger('sayHi'); // logs Hi!

But those events won't go up in the tree.

The way freezer works, whenever you call a updating function in the tree, it triggers the update event in the listeners of all the nodes from the node that is being updated to the top. But triggering an event in a node is a single operation that doesn't propagate through the tree like the updates do.

from freezer.

One little gotcha with this, that is easy to workaround when you know about it is:

var store = new Freezer({a: {b: [1,2,3]}}),
  listener = store.get().a.b.getListener()
;

listener.on('update', () => console.log('Update'));

store.get().a.set("b", [1,2,4]) // does not trigger an event

from freezer.

hi @bep, shouldnt it trigger? quote : it triggers the update event in the listeners of all the nodes from the node that is being updated to the top.;

So what is the correct way to listen for update?

@arqex I like the your "observable" solution compared to flux, flux is way more complicated

from freezer.

hi @bep, shouldnt it trigger?

Maybe ... but it, in the example, you set b, I guess you're replacing it ... and then the listener is gone ... ? My point is, a workaround is to pull the listener one level up.

from freezer.

Sorry @bep I forgot to reply to your last comment.

When you set a child, you are replacing the child node by a new one, so the listener of the node is gone too.

You can also reset the node, instead of replacing it and the listener should be kept

store.get().a.b.reset([1,2,4]);

http://jsbin.com/sojupatogo/1/edit?js,console

When a change is made, the update event is triggered in all the parents, so you could listen to changes in all those nodes. But I would highly recomend not to add listeners in the nodes and isolate partial rendering depending on those events.

Fine grained rendering makes your app much more complex and difficult to understand, soon you will find yourself asking why is some part of the app not being updated after a change. You should listen to the top node events and re-render your whole app when any change happens, you will be amazed how performant is react's diff algorithm.

If you think that the performance is not good enough, it is much easier to declaratively stop re-rendering some part when the props don't change (à la pureRenderMixin since react data is immutable this is really easy) than imperatively re-render the part of the store that are changing.

from freezer.

Clear answer

from freezer.