Skip to content

Instantly share code, notes, and snippets.

@lsmith
Last active December 14, 2015 16:49
Show Gist options
  • Select an option

  • Save lsmith/5117861 to your computer and use it in GitHub Desktop.

Select an option

Save lsmith/5117861 to your computer and use it in GitHub Desktop.
Getting an idea of what the expectation of behavior between on() and after() phase of a stopped event is.
var child = new Y.EventTarget({ emitFacade: true }),
parent = new Y.EventTarget({ emitFacade: true }),
grandparent = new Y.EventTarget({ emitFacade: true });
child.addTarget(parent);
parent.addTarget(grandparent);
child.publish('foo', {
defaultFn: function () { console.log("default function"); }
});
child.on('foo', function (e) { console.log('child.on()'); });
parent.on('foo', function (e) {
console.log('parent.on()');
e.stopPropagation();
});
grandparent.on('foo', function (e) { console.log('grandparent.on()'); });
child.after('foo', function (e) { console.log('child.after()'); });
parent.after('foo', function (e) { console.log('parent.after()'); });
grandparent.after('foo', function (e) { console.log('grandparent.after()'); });
child.fire('foo');
// What do you think should be logged?
@rgrove
Copy link
Copy Markdown

rgrove commented Mar 8, 2013

Cripes, you added that defaultFn while I was typing my comment. In that case:

  • child.on()
  • parent.on()
  • defaultFn()
  • child.after()
  • parent.after()

@solmsted
Copy link
Copy Markdown

solmsted commented Mar 8, 2013

I think I agree with @rgrove, the on phase bubbles up, then defaultFn, then the after phase bubbles up.

So

child.on()
parent.on()
default function
child.after()
parent.after()

However, this result means that stopPropagation in the on phase automatically stops propagation in the after phase. Is there any way to split up this functionality so I could stop propagation in the on phase while allowing propagation in the after phase?

@seldo
Copy link
Copy Markdown

seldo commented Mar 8, 2013

Okay, with the defaultFn, things don't change too much. Again, my expectation and my ideal behaviours differ:

I'd expect this to happen:

child.on()
parent.on()
default function
child.after()

But contrary to what others have said, I would want this to happen:

child.on()
default function
child.after()
parent.on()
parent.after()

To me it seems more logical that the after() of a child should precede the on() of a parent, and also it seems more convenient to fire the after() event even if propagation has stopped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment