Hi Billy,
Those are good questions, I like them. However, I can’t answer them with a short response, I don’t like that :-P I will comment on some stuff inline, and elaborate at the end. Note: we should never use $watch in a controller: It makes it difficult to > test the controller. > We’re making an allowance here for the sake of illustration, and we’ll > move these watches > into services later. > > Ok, I like Ari, and I like his book. Actually he is giving this same advice twice in the book! And then there are also quite some samples in the book using $watch in controllers. I’m going to make an allowance here and go into detail later ;) http://www.benlesh.com/2013/10/title.html > Ok, did you read the comments too? I will address this too later on! as far as that line if (element[0].name === 'appointment_type') > > for some reason I plnkr I had to do that instead of element.context.name I > am reading a lot about angular and definitely try to take the "best > practices". Everywhere I read I am told to keep controllers short if > possible and only use them for scope related things. DOM manipulation > should happen in directives etc and not having watch events in controllers > is one of the things I keep seeing > Ok, the problem is in the element part. You are fetching data from the DOM/HTML that is the part that is bothering me! In a angular app, the DOM/HTML is a result of your program, not a part of it! The only time you are allowed to read out of it is if you need something from a 3rth party thing, and the reading should be encapsulated in a directive. I plan on using a directive if I use watch events like you did the next > question is...it is easy to grab the attributes of an element in the link > function so that is why I did it that way. What other way can I grab the > attributes of an element when I have something like ng-change on it? can I > pass the event ($event) and grab the data from there? > In a directive you can use the attr parameter of the link function. Also you can simply watch the scope in a directive. Or put in the needed variables into a parameter, here is a small example of that: <input type='text' ng-model='name' ng-change='updateSomething(name)'> I agree what you have works and I take your advice very serious because you > are very knowledgeable on all kinda of topics here but I have read too much > that says not to use watch events in angular so how else can we do this > that satisfies not doing that but also I don't do what I am doing since you > don't think its a good idea > Well, opinions matter! Some of those mature into best practices. Some don’t. Some of the best practices survive, and some don’t. There was a time that having long and descriptive variable names was frowned upon. (way back, when 4kb memory was considered a lot!, I remember writing whole programs full of variables names like ‘a’, ‘b’ and ‘c’.) I don’t want to say you don’t need to follow best practices, but do not follow them blindly! There are times that actually following those will add complexity to your codebase without adding any benefits. Ok, I promised to come back to you on the statement in the ng-book, so here I go. There is wisdom in the advice Ari is giving you, and there are reasons to do it that way. If you really understand those reasons, you can make a decision on when to comply and when to reject the 'best practice'. One of the main reasons for giving this advice is that it is really easy to use $watch wrongly. By wrongly I mean, putting in way to many, or use performance intensive expressions/function on the watch. Ari has this subject covered in his book. Another reason is that it is making it harder to unit-test your controller. This is a whole subject on its own, and out of the scope of this discussion. For this argument let me just say that's not a valid reason. There are more reasons, and every reason has its equally valid counter argument. If you know one, I will be happy to discuss it with you. I'm pretty sure I can come up with evidence of the opposite :-) (even if the opposite is disagreeing with my own idea about it!) Ok. Back to your sample. I updated my plunk a little bit to aid in testability. If you prefer, you can now easily use ng-change if you prefer that. However, if you use ng-change, in stead of the $watch, it is no longer clear from the code alone what is happening, you have to examine the template to get the picture complete. For that reason alone I prefer a $watch, although that’s not the only reason. Every piece of code has responsibility. In the sample I gave the $watch is responsible for: 1. Monitoring the model 2. fetching data from the service 3. updating the view As in what you needed was really simple I just putted it in a watch. However, If I would have followed best practice to the letter I would have ended up with: 1. a service for monitoring the model and fetching the date data 2. a service for monitoring the model and fetching the time data 3. a directive to monitor the model and update the date view 4. a directive to monitor the model and update the time view As I probably don't like to write out 2 of each I would combine those together, making both the service and the directive more complex to write, test and maintain. Can you explain me the gain in this scenario? This is not a rhetorical question, I’m really interested in your answer! Regards Sander -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/d/optout.
