angular-hammer
angular-hammer copied to clipboard
RyanMullins
Option to disable callable return values
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.
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).
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.
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.