At what point one should stop adding ng-[event] and use element.on("[event]") in AngularJS?

Question

I'm making an app that uses a lot of events, and I ended up with more than 6 event listeners in one root element in a directive. Is that OK? Should I use ng-events every time when possible, when is OK to use element.on?

I have to admit that is much cleaner to see the events that affect each element directly on the views, but I don't know if it's right, it feels kind of dirty to mix so many functions in the views.

The amount of event listeners should not really matter, unless you are running the same one multiple times for the same element. — Entoarox, Jan 07 '14 at 18:09

score 1 · Answer 1 · edited May 23 '17 at 12:19

1

**ng-[events]** are use manipulate the Model.

While element.on (jquery I would assume) works outside angular scope it should not be used when working with the Model(manipulate data).

Angular allows to create somehting called directives, if you ever need to manipulate the Model(data) it is there where elemnent.on makes more sense because it is the purpose of the directive to link your DOM with the Model/Controller.

Please visit this link to learn the "Angular way"

http://blog.markmun.com/?p=409

The "angular way" is also widely discussed here:

"Thinking in AngularJS" if I have a jQuery background?

edited May 23 '17 at 12:19

Community

1
1

answered Jan 07 '14 at 18:12

Dalorzo

19,834
7
55
102

1

You probzbly missed the _"in one root element **in a directive**"_ part. OP obviously knows about directives (and uses them already). – gkalpak Jan 07 '14 at 18:34
@ExpertSystem Even inside directives the principal explained applies. That is why this is mentioned as the "angular way". I do not understand why you think this answer is responding the question – Dalorzo Jan 07 '14 at 18:41
Didn't know the `on` was added by jQuery. So angular just have `bind`? – Zequez Jan 07 '14 at 18:42
@Dalorzo: The principle holds, but it is not related with the question. The principle is about DOM manipulation in Angular, while the question is about registering event listeners. OP is already using directives and probably familiar with the Angular way of manipulating the DOM. – gkalpak Jan 07 '14 at 18:43
The question is whether or not it is correct or the angular way isn't it? It is implied in "Is it OK?" – Dalorzo Jan 07 '14 at 18:44
`on` and `bind` are both supported. – Nathaniel Johnson Jan 07 '14 at 18:46
on and bind are part of JQueryLite @NathanielJohnson if is that what you are referring to. But it does not mean that it should be used arbitrary and contradicting MVVM principles. Do you agree? – Dalorzo Jan 07 '14 at 18:47
According to **[the docs](http://docs.angularjs.org/api/angular.element)**, `on` and `bind` are "synonyms" (and part of jqLite) and provide functionality similar to jQuery's `on`, **but** do not support namespaces, selectors or eventData. – gkalpak Jan 07 '14 at 18:49
1

I think we can think of this question as what theoretical principal applies in order to make the right decision or saying from our POV what is the right decision. I still believe the decision lies in understanding what is the purpose of each and letting @Zequez decide based on that information – Dalorzo Jan 07 '14 at 18:52
1

@Dalorzo Yes I agree, however I wouldn't know how else to bind an event in a custom directive. @ExpertSystem - Yes but they are both `supported` via jqLite even if they are synonyms. I do not know if one is preferred above the other. – Nathaniel Johnson Jan 07 '14 at 18:52
2

I am glad to see that an opinion brought all this healthy discussion. I appreciate all your comments I have learned a few things from them – Dalorzo Jan 07 '14 at 18:55

Nathaniel Johnson · Answer 2 · 2014-01-07T18:33:16.850

1

It is probably time to create a directive that wraps the functionality of all those event listeners. That is, assuming that you use the same sets of listeners repeatedly and the functionality of those listeners is always the same and can be abstracted out of the specific controller for the view and into the directives own generic controller.

app.directive('MyEventHandler', function(){ 
   return {
      restrict: 'A', //attribute only
      link: function(scope, elem, attr, ctrl) {
         elem.bind('mouseenter', function(e) {
            //do something here.
         });
         elem.bind('mouseleave', function(e) {
            //do something here.
         });
         elem.bind('click', function(e) {
            //do something here.
         });
         elem.bind('dblclick', function(e) {
            //do something here.
         });
      }
   };
});

Until then formatting them by giving each one a separate row is a good way to manage the visual shock.

edited Jan 07 '14 at 18:33

answered Jan 07 '14 at 18:20

Nathaniel Johnson

4,731
1
42
69

1

Although is not applicable in all events I'm working on, I'll keep it in mind to implement a dragging ng-event, thanks! – Zequez Jan 07 '14 at 18:37
@Zequez It is the many angular events on a tag issue? You don't have common behavior? – Nathaniel Johnson Jan 07 '14 at 18:40
I also meant to ask if by `directive` (which I finally saw after re-reading three times!!!) You were referring to a custom directive? – Nathaniel Johnson Jan 07 '14 at 18:45
There are some of those events that are associated to dragging feature, those I can separate in a custom event-directive, but the other ones just point to different methods of the scope. – Zequez Jan 07 '14 at 18:59
Yeah, I am starting to see this in more of my html too. I have read that some people discouraged this approach (angular) for just that reason but I still like to see the function mapping in the html. Like I suggested, I just put each directive on its own line and it becomes pretty readable. – Nathaniel Johnson Jan 07 '14 at 19:02

At what point one should stop adding ng-[event] and use element.on("[event]") in AngularJS?

2 Answers2