AngularJS MTV Meetup: Best Practices (2012/12/11)
Why Stack Overflow recommends it
Stack Overflow users link it when answering AngularJS scope and architecture questions, especially the 'always have a dot in ng-model' rule and why shared state belongs in services rather than controllers.
Recommended by 51 people across 44 different months, 2012 to 2020.
What it is
A recorded AngularJS MTV meetup session in which Miško Hevery, the creator of Angular, walks through best practices for structuring AngularJS apps. Topics include controllers versus scope, prototypal scope inheritance, services for shared state, and directive and module layout.
What people said
Strong rec holographic-principle · 2013-06 · Stack Overflow · on “How to master AngularJS?”
This is the most comprehensive AngularJS learning resource repository I've come across: AngularJS-Learning [LINK] To pluck out the best parts (in recommended order of learning): [LINK] - Series of short, to the point AngularJS videos AngularJS Cheatsheet [LINK] - regularly updated cheatsheet [latest update 13th February, 2013] On nested scopes [LINK] - Points out possible problems when using scope inheritance (references a good talk [this video] by Misko Hevery that you should also watch) Dependency injection [LINK] - Official developer guide on DI Dependency injection [LINK] - More on AngularJS dependency injection "Service or Factory?" [LINK] - Differences between the various types of providers
Strong rec shaunhusain · 2013-07 · Stack Overflow · on “angular view not updating from shared service”
The answer is a service... I should buy the domain theanswerisaservice.com it's so often the answer on SO questions for AngularJS. If you need to maintain persistent state of some objects across the life of the application (for the sake of sharing data and not creating extra requests) a service is the solution. [this video] < I suggest watching the whole talk many times when you have time.
Strong rec KayakDave · 2013-10 · Stack Overflow · on “Call a method of a controller from another controller using 'scope' in AngularJS”
Each controller has it's own scope(s) so that's causing your issue. Having two controllers that want access to the same data is a classic sign that you want a service . The angular team recommends thin controllers that are just glue between views and services. And specifically- "services should hold shared state across controllers". Happily, there's a nice 15-minute video describing exactly this (controller communication via services): video [LINK] One of the original author's of Angular, Misko Hevery, discusses this recommendation (of using services in this situation) in his talk entitled Angular Best Practices [this video] (skip to 28:08 for this topic, although I very highly recommended watchi
Recommends Umur Kontacı · 2013-01 · Stack Overflow · on “AngularJS - Evaluating options to a directive in the correct scope”
<span color-codify="{'max' : object.max, 'value' : object.value}" ng-transclude> {{ object.value }} <a href="#">Edit</a> | <a href="#">Delete</a> </span> . myModule.directive('colorCodify', function() { return { restrict: 'A', transclude: 'true', scope: {getOpts: "&colorCodify"}, 'link' : function(scope, element, attrs, controller) { var opts = scope.getOpts(); console.log(opts); } } }); For more info, check out directive definition object part in [LINK] Edit about $parent: I suppose you need to read more about how scopes work in angular (how do they inherit from one another and how do they override those inherited properties). This would be one of the most important aspects in angularjs. I
Recommends Mark Rajcok · 2013-03 · Stack Overflow · on “Behavior of assignment expression invoked by ng-click within ng-repeat”
As @Stewie mentioned, $parent is one way to solve this issue. However, the recommended ( by the Angular team [this video] ) solution is to not define primitive properties on the $scope. Rather, the $scope should reference your model. Using references also avoids the issue (because primitive properties will not be created on the child scopes which hide/shadow the parent scope properties of the same name), and you don't have to remember when to use $parent: HTML: <p>Selected = {{model.selected}}</p> <hr/> <p ng-click='model.selected = defaultValue'>Click me</p> <hr/> <p ng-repeat='value in values' ng-click='model.selected = value'>{{value}}</p> <hr/> <p ng-repeat='value in values' ng-click='doSelec
Recommends Bart · 2013-04 · Stack Overflow · on “Show pop-ups the most elegant way”
It's funny because I'm learning Angular myself and was watching some video's from their channel on Youtube. The speaker mentions your exact problem in this video [this video] around the 28:30 minute mark. It comes down to placing that particular piece of code in a service rather then a controller. My guess would be to inject new popup elements into the DOM and handle them separate instead of showing and hiding the same element. This way you can have multiple popups. The whole video is very interesting to watch as well :-)
Recommends Ryan Q · 2013-04 · Stack Overflow · on “Structuring my AngularJS application”
Sam's method seems to be the way to go in most cases. The current Angular documentation has it setup as a module for each controller, service, etc, but this has been contradicted by Miško himself from google. In a recent Angularjs Best Practices [this video] video by Miško, he shows how the structure of modules could be laid out for ease of testing as well as easy scaling. Keep in mind how you structure the modules is not supposed to affect performance within an angular app. From developing angular apps, I would suggest using the best practices method for the aforementioned reasons. You may wish to make your own node script to generate your controllers, etc for the time being which could include
Recommends Michelle Tilley · 2013-04 · Stack Overflow · on “Shouldn't there be an AngularJS ngWith directive?”
This is a great question. I can see how this may be confusing coming from another front-end framework, but in Angular, the scope has a reference to the model, and the syntax you're describing is normal. I personally like to describe the scope as more like a view model [LINK] . Miško Hevery, the author of AngularJS, does a good job of explaining this concept in this video, starting at about the 30 minute mark and lasting about 3 minutes [this video] : People oftentimes think that the scope is the model, and that's not the case. Scope has references to the model. [...] So in the view, you say model dot whatever property you want to access. While it may be possible to write an ngWith directive that
Recommends Scott Silvi · 2013-05 · Stack Overflow · on “AngularJS : The correct way of binding to a service properties”
I think this question has a contextual component. If you're simply pulling data from a service & radiating that information to it's view, I think binding directly to the service property is just fine. I don't want to write a lot of boilerplate code [LINK] to simply map service properties to model properties to consume in my view. Further, performance in angular is based on two things. The first is how many bindings are on a page. The second is how expensive getter functions are. Misko talks about this here [this video] If you need to perform instance specific logic on the service data (as opposed to data massaging applied within the service itself), and the outcome of this impacts the data model
Recommends JHixson · 2013-05 · Stack Overflow · on “Require login per controller/view (Angular JS)”
A service is very appropriate in this case. As described in this video [this video] about best practices, Services aren't as much about "Getting data", as it is separation of logic from the controller. A controller says what to do, a service says how to do it. So, in your case, a Controller says "I need to check if the user is authenticated" but to know how to do that, it depends on a service. This fits perfectly with the data-gathering concept as well. A controller says "I need to get all of the Employee Information." The service defines how. He specifically says in this meeting that whenever there is information that needs to be shared between controllers, a service is pretty much always the be