RyanMullins / angular-hammer

Hammer.js v2 support for AngularJS
http://ryanmullins.github.io/angular-hammer/
MIT License
188 stars 55 forks source link

requireFailure.. um, failure #14

Closed cognivator closed 9 years ago

cognivator commented 9 years ago

I'm not clear on how to wire up several recognizers with requireFail via the hmRecognizerOptions attribute... if it's even possible. My perusal of the source left me with the impression it could be done, but I'm having a problem with sequencing the creation of the recognizers on a given element. To see the problem firsthand, take the existing default demo, and add the following hm-recognizer-options attribute,

    <div id="target"
      ng-controller="hmCtrl"
      hm-pan="onHammer"
      hm-pinch="onHammer"
      hm-press="onHammer"
      hm-rotate="onHammer"
      hm-swipe="onHammer"
      hm-tap="onHammer"
      hm-doubletap="onHammer"
      hm-recognizer-options='[
      {"type":"pan","requireFailure":"swipe"}
      ]'>
      {{eventType}}
    </div>

My hope was this would cause pan to be recognized only after swipe fails. However, stepping through the code reveals that the swipe recognizer has not been instantiated when pan is trying to reference it during the requireFail call. It's also not clear how this would ever work since requireFailure (in HammerJS) automatically creates the reverse reference as well. In short, it appears both recognizers have to be instantiated before calling requireFailure, but angular.hammer.js treats the recognizer-options on creation of each recognizer.

Am i missing a trick somewhere? Or will I be creating my own directive that manages the requireFailure (and/or recognizeWith) wiring?

RyanMullins commented 9 years ago

Hmm... Hmm... I see exactly what you're saying, and that is going to cause a problem. Let me think about this for a bit. I'm in the middle of end-of-the-year wrap up at work, but will have time to take a look at this either late next week or the week after.