search

RyanMullins / angular-hammer

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

Option to disable callable return values #32

Open nateabele opened 9 years ago

nateabele commented 9 years ago

First of all, thanks for porting this library to Hammer v2.

So, this guy has been giving me no end of trouble.

I write my JS to be as composable as possible, which means two things: (1) the internal logic doesn't know anything about the UI, (2) most things return functions.

Even accounting for this, whenever you integrate a 3rd-party lib you have no control over, you need to make sure you wrap all your calls in something that'll nuke the return value. I get why the behavior is the way it is, but it'd sure be nice to have a module-level setting to disable it.

Lemme know if this seems reasonable and if you'd like a PR.

RyanMullins commented 9 years ago

So I might need more clarification, but this seems like you want a flag that I can use to disable the execution of the function parsed from the expression? The easiest way to integrate this (and it is very easy) would be with an extension to the recognizer option, we could call it preventExecution or something like that. Would that work for you?

I don't know that I want a module-level flag given that I could want it in some cases but not in others (I don't really have a use case in mind, but it's a situation that could theoretically exist).

nateabele commented 9 years ago

The easiest way to integrate this (and it is very easy) would be with an extension to the recognizer option, we could call it preventExecution or something like that. Would that work for you?

Strictly speaking, yes, but the ultimate goal is to specify that in one place. (Or are you suggesting that's possible by adding recognizer options?).

I don't know that I want a module-level flag given that I could want it in some cases but not in others (I don't really have a use case in mind, but it's a situation that could theoretically exist).

Maybe a module-level configuration for default recognizer/manager options would be more generically useful? In my case, I know that I never want return values to be directly acted upon by handlers, so being able to specify that in one place would be great.

Hopefully that makes sense and I'm understanding you correctly.

RyanMullins commented 9 years ago

Hmm... I forgot about the config settings in Angular (rarely use them myself). Let me think about that approach. I am in the process of revamping the way I define recognizer and manager options for v2.2 already, so this could just be added to that work.

nateabele commented 9 years ago

Nice, thanks man.