Skip to content

Instantly share code, notes, and snippets.

@lsmith
Last active December 14, 2015 16:49
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save lsmith/5117861 to your computer and use it in GitHub Desktop.
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?
@seldo
Copy link

seldo commented Mar 8, 2013

Is this a poll or a basic interview question? :-)

To me it looks like the log should ideally be:
child.on()
child.after()
parent.on()
parent.after()

But I can think of implementation issues that might make this happen:
child.on()
parent.on()
child.after()

And that's logical enough that it wouldn't make me violently angry or anything, but the former would be more useful.

@lsmith
Copy link
Author

lsmith commented Mar 8, 2013

@seldo

Sorry, I added a defaultFn to clarify the on() and after() relate to the defaultFn. But your response is definitely interesting in the context of an event without a defaultFn.

@rgrove
Copy link

rgrove commented Mar 8, 2013

I would expect:

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

Since the "on" phase is essentially present tense (occurring either while or just before a thing happens), all targets' "on" handlers should run before any "after" handlers run. And since propagation is stopped in the "on" phase of the parent, the event should not bubble to grandparent in any phase.

@tivac
Copy link

tivac commented Mar 8, 2013

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

OR

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

@rgrove
Copy link

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

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

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