views:

461

answers:

5

Imagine I have this code:

var myFunc1 = function(event) {
    alert(1);
}
var myFunc2 = function(event) {
    alert(2);
}

element.addEventListener('click', myFunc1);
element.addEventListener('click', myFunc2);

When the click event is fired myFunc1 is called, then myFunc2. But how do I (if at all possible) stop myFunc2 from being called if some condition in myFunc1 is met? event.stopPropagation() is not the solution, as this is not an event capturing/bubbling problem.

Thanks.

+1  A: 

I'll start with the simplest answer that satisfies the constraints you've given so far. If it doesn't meet some condition you haven't yet specified, let me know and I'll update it.

Only allow one click handler, and call functions based on conditions there. Your test code becomes:

var myFunc1 = function(event) {
    alert(1);
}
var myFunc2 = function(event) {
    alert(2);
}
var clickHandler = function(event) {
    if (f1active) myFunc1(event);
    if (f2active) myFunc2(event);
}

element.addEventListener('click', clickHandler);
var f1active = true;
var f2active = true;

and you can of course put any conditions you want to in clickHandler.

llimllib
The trouble is a) I'm not always using both listeners at the same time, and b) the listeners are added in different components within a large, modular library of code, so merging them not only makes no sense, but would also be fairly difficult.
Jack Sleight
+1  A: 

Still looking for a better solution, but this may be the only way to do it:

var myFunc1 = function(event) {
    alert(1);
    if (something) {
     event.cancel = true;
    }
}
var myFunc2 = function(event) {
    if (event.cancel) {
     return;
    }
    alert(2);
}

document.body.addEventListener('click', myFunc1, false);
document.body.addEventListener('click', myFunc2, false);

Thoughts/comments welcome.

Jack Sleight
+1  A: 

The DOM Level-3 method event.stopImmediatePropagation is exactly what I need here, unfortunately it's not currently implemented in any browser (that I know of).

http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/events.html#Events-Event-stopImmediatePropagation

Jack Sleight
+4  A: 

There's a further problem: the order that event listeners are executed is undefined. You'll need to handle event dispatch on your own to get around this, which leads us to some variant of llimllib's suggestion.

function dispatchSleightEvent(evt) {
    var listeners = evt.currentTarget.sleightListeners[evt.type];
    // can't use for-in because enumeration order is implementation dependent
    for (var i=0; i<listeners.length; ++i) {
       if (listeners[i]) {
         if (! listeners[i].call(evt.currentTarget, evt)) {
           return false;
         }
       }
    }
    return true;
}

function mixinSleightTarget(obj) {
  if (! obj.sleightListeners) {
    obj.sleightListeners = {}
    obj.addSleightListener = function(type, listener) {
        if (!this.sleightListeners[type]) {
            this.sleightListeners[type] = [];
            this.addEventListener(type, dispatchSleightEvent);
        }
        if (!this.sleightListeners[type+listener] {
          this.sleightListeners[type+listener] = this.sleightListeners[type].length;
          this.sleightListeners[type].push(listener);
        }
    }
    obj.removeSleightListener = function(type, listener) {
        if (this.sleightListeners[type+listener] {
          delete this.sleightListeners[type][this.sleightListeners[type+listener]];
          delete this.sleightListeners[type+listener];
        }          
    }
  }
}

This code is completely untested. To stop event dispatch while on a single target, an event listener returns false. If you want more data hiding, you can rewrite the above from a functional programming standpoint, though this might introduce memory leaks.

outis
Until stopImmediatePropagation() is implemented a custom event handler is the best solution, so I've marked it as the answer. Although you're correct that the order is undefined, it is defined in DOM Level-3 (FIFO), and every test I've done in Gecko suggests that this order is consistent in the current implementation (this is for an internal app that only needs to work in FF3). For nothing but the sake of simplicity for the time being, I've currently opted for a solution similar to my first anwser.
Jack Sleight
There's one issue I was worried about, the order that the listeners are added, but it sounds like that's not a problem for now. A better design would support explicit listener dependencies.
outis
+1  A: 

Hi Jack, I second the outis solution, sounds like you need to decorate or adapt the existing DOM event dispatching model with your own event dispatcher.

Did some searching and found this link, which may or may not suit your needs, based on an actionscript dispatcher implementation, dated 2007.

http://positionabsolute.net/blog/2007/06/event-dispatcher.php

Of course I'm not really a javascripter, so give me a heads up if this is not relevant.