Trigger event on child nodes?

[rahatarmanahmed]

The docs say you can listen to child nodes but can you trigger an event on child nodes? Do events trickle up and down the tree? Documentation could be more clear about this

[arqex]

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.

[bep]

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

[x4080]

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

[bep]

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.

[arqex]

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.

[x4080]

Clear answer