If the right way to share data between controllers are using factory/service, what is the purpose of the $rootScope?
$rootScope exists, but it can be used for evil
Scopes in Angular form a hierarchy, prototypally inheriting from a root scope at the top of the tree. Usually this can be ignored, since most views have a controller, and therefore a scope, of their own.
Occasionally there are pieces of data that you want to make global to the whole app. For these, you can inject $rootScope and set values on it like any other scope. Since the scopes inherit from the root scope, these values will be available to the expressions attached to directives like ng-show just like values on your local $scope.
Of course, global state sucks and you should use $rootScope sparingly, like you would (hopefully) use with global variables in any language. In particular, don't use it for code, only data. If you're tempted to put a function on $rootScope, it's almost always better to put it in a service that can be injected where it's needed, and more easily tested.
Conversely, don't create a service whose only purpose in life is to store and return bits of data.
-- AngularJS FAQ
As per my understanding.
you can use $rootScope in multiple places .
global settings defined in factory and then in view you can update as per your condition. f.x layout manipulation
you can assigned $state on run.
you can handle error ($rootScope.$on(...)
I hope this will help.
Thanks
This question already has answers here:
'this' vs $scope in AngularJS controllers
(7 answers)
Closed 7 years ago.
I can access controller variable on markup by using controller alias dot(.) variable name, so why we need $scope separately.. can we use the controller context and $scope interchangeably .. or there is some thing specific for which $scope is designed.
This is a good question, but perhaps too broad to get single clear answer. I'll offer my thoughts.
$scope was designed to be the view's model - the "VM" in MVVM pattern.
controller-as was introduced to follow an MVC pattern more closely where $scope inheritance is overkill and unnecessary. The "C" corresponds to an Angular controller, and allows the view to trigger a controller action directly.
I think the introduction of controller-as was a nice change. But I believe the right way to use it is for calling methods that is under the immediate control of the controller. In my opinion, I think that methods in controller scope should not propagate up the $scope stack, and call another method higher up the $scope chain. Doing so introduces complex dependencies, which is hard to understand and maintain. Controller-as prevents that.
Although controller-as can be used for storing models (not just for calling methods), I don't believe that it should. That is the job of the view model or $scope. I know others might feel differently.
$scope is not a singleton service. Meaning, when we inject it somewhere, usually it will create a new child scope. So, using $scope, we can propagate events for all its parents/children.
Also, we can store some "global" variables methods in parent scope.
If you use controller-as syntax, you are not able to work with this nesting. But code becomes more predictible.
I'm really new on AngularJS and i don't know the best practices so here is my question.
What is the recommended use of parents controllers properties? Should I use different alias trough the entire webapp or there is another way to use vars and methods of a parent controller?
I'm using partials html and seems it can be confusing see userCtrl.doSomething when the partial has no declaration of userCtrl (because its declared on a partial thats includes this one).
Thanks in advance!
You should avoid to use $parent and scope variables that are not declared in your controller.
Why ? Because if you use it, your controller will be directly dependent to where you instantiated it (ng-controller). So you won't respect the MVC pattern. Your controllers should not be dependent on the View.
Your controller should not know what are his parents. Because you can do it doesn't means that you should to it.
To share data between controllers, use Services instead. That's easier and cleaner.
I have a controller where the $scope object has been used to store methods and values that are only used locally within the same controller. There is a lot of this going on:
$scope.foo = 'something';
$scope.bar = 'something else';
... and so on. None of these values are used within the view. My question is does polluting the $scope object affect performance? Is it a good idea to clean this up so only values and methods needed for the view are contained in the $scope object?
Yes, Polluting $scope does affect performance, but its depends your scope has multiple watchers which are frequently changing then that will create a more overhead cost. Refer this answer which has covered same point
For avoiding this situation I'd suggest you to do good re-factoring of code
Handle all the logic in controller whenever required otherwise do separate a logic by making good use of each component.
Move common method(logic) to service/factory/provider which is used in multiple place, so that it would be sharable.
If some value are fixed, they are not gonna change then move them to constant/value
Whenever you feel like you have same logic which needs to be keep in $scope it self then move that logic to common controller. When required you could inject in your current controller scope using $controller injector
Also refer Understanding Of Scope for clear understanding of use of scope
I'm looking for some guidelines that one can use to help determine which type of scope to use when writing a new directive. Ideally, I'd like something similar to a flowchart that walks me through a bunch of questions and out pops the correct answer – no new new scope, new child scope, or new isolate scope – but that is likely asking for too much. Here's my current paltry set of guidelines:
Don't use an isolated scope if the element that will use the directive uses ng-model
See Can I use ng-model with isolated scope? and Why formatters does not work with isolated scope?
If the directive doesn't modify any scope/model properties, don't create a new scope
Isolate scopes seem to work well if the directive is encapsulating a set of DOM elements (the documentation says "a complex DOM structure") and the directive will be used as an element, or with no other directives on the same element.
I'm aware that using a directive with an isolated scope on an element forces all other directives on that same element to use the same (one) isolate scope, so doesn't this severely limit when an isolate scope can be used?
I am hoping that some from the Angular-UI team (or others that have written many directives) can share their experiences.
Please don't add an answer that simply says "use an isolated scope for reusable components".
What a great question! I'd love to hear what others have to say, but here are the guidelines I use.
The high-altitude premise: scope is used as the "glue" that we use to communicate between the parent controller, the directive, and the directive template.
Parent Scope: scope: false, so no new scope at all
I don't use this very often, but as #MarkRajcok said, if the directive doesn't access any scope variables (and obviously doesn't set any!) then this is just fine as far as I am concerned. This is also helpful for child directives that are only used in the context of the parent directive (though there are always exceptions to this) and that don't have a template. Basically anything with a template doesn't belong sharing a scope, because you are inherently exposing that scope for access and manipulation (but I'm sure there are exceptions to this rule).
As an example, I recently created a directive that draws a (static) vector graphic using an SVG library I'm in the process of writing. It $observes two attributes (width and height) and uses those in its calculations, but it neither sets nor reads any scope variables and has no template. This is a good use case for not creating another scope; we don't need one, so why bother?
But in another SVG directive, however, I required a set of data to use and additionally had to store a tiny bit of state. In this case, using the parent scope would be irresponsible (again, generally speaking). So instead...
Child Scope: scope: true
Directives with a child scope are context-aware and are intended to interact with the current scope.
Obviously, a key advantage of this over an isolate scope is that the user is free to use interpolation on any attributes they want; e.g. using class="item-type-{{item.type}}" on a directive with an isolate scope will not work by default, but works fine on one with a child scope because whatever is interpolated can still by default be found in the parent scope. Also, the directive itself can safely evaluate attributes and expressions in the context of its own scope without worrying about pollution in or damage to the parent.
For example, a tooltip is something that just gets added; an isolate scope wouldn't work (by default, see below) because it is expected that we will use other directives or interpolated attributes here. The tooltip is just an enhancement. But the tooltip also needs to set some things on the scope to use with a sub-directive and/or template and obviously to manage its own state, so it would be quite bad indeed to use the parent scope. We are either polluting it or damaging it, and neither is bueno.
I find myself using child scopes more often than isolate or parent scopes.
Isolate scope: scope: {}
This is for reusable components. :-)
But seriously, I think of "reusable components" as "self-contained components". The intent is that they are to be used for a specific purpose, so combining them with other directives or adding other interpolated attributes to the DOM node inherently doesn't make sense.
To be more specific, anything needed for this standalone functionality is provided through specified attributes evaluated in the context of the parent scope; they are either one-way strings ('#'), one-way expressions ('&'), or two-way variable bindings ('=').
On self-contained components, it doesn't make sense to need to apply other directives or attributes on it because it exists by itself. Its style is governed by its own template (if necessary) and can have the appropriate content transcluded (if necessary). It's standalone, so we put it in an isolate scope also to say: "Don't mess with this. I'm giving you a defined API through these few attributes."
A good best practice is to exclude as much template-based stuff from the directive link and controller functions as possible. This provides another "API-like" configuration point: the user of the directive can simply replace the template! The functionality all stayed the same, and its internal API was never touched, but we can mess with styling and DOM implementation as much as we need to. ui/bootstrap is a great example of how to do this well because Peter & Pawel are awesome.
Isolate scopes are also great for use with transclusion. Take tabs; they are not only the whole functionality, but whatever is inside of it can be evaluated freely from within the parent scope while leaving the tabs (and panes) to do whatever they want. The tabs clearly have their own state, which belongs on the scope (to interact with the template), but that state has nothing to do with the context in which it was used - it's entirely internal to what makes a tab directive a tab directive. Further, it doesn't make much sense to use any other directives with the tabs. They're tabs - and we already got that functionality!
Surround it with more functionality or transclude more functionality, but the directive is what it is already.
All that said, I should note that there are ways around some of the limitations (i.e. features) of an isolate scope, as #ProLoser hinted at in his answer. For example, in the child scope section, I mentioned interpolation on non-directive attributes breaking when using an isolate scope (by default). But the user could, for example, simply use class="item-type-{{$parent.item.type}}" and it would once again work. So if there is a compelling reason to use an isolate scope over a child scope but you're worried about some of these limitations, know that you can work around virtually all of them if you need to.
Summary
Directives with no new scope are read-only; they're completely trusted (i.e. internal to the app) and they don't touch jack. Directives with a child scope add functionality, but they are not the only functionality. Lastly, isolate scopes are for directives that are the entire goal; they are standalone, so it's okay (and most "correct") to let them go rogue.
I wanted to get my initial thoughts out, but as I think of more things, I'll update this. But holy crap - this is long for an SO answer...
PS: Totally tangential, but since we're talking about scopes, I prefer to say "prototypical" whereas others prefer "prototypal", which seems to be more accurate but just rolls off the tongue not at all well. :-)
My personal policy and experience:
Isolated: a private sandbox
I want to create a lot of scope methods and variables that are ONLY used by my directive and are never seen or directly accessed by the user. I want to whitelist what scope data is available to me. I can use transclusion to allow the user to jump back in at the parent scope (unaffected). I do NOT want my variables and methods accessible in transcluded children.
Child: a subsection of content
I want to create scope methods and variables that CAN be accessed by the user, but are not relevant to surrounding scopes (siblings and parents) outside the context of my directive. I also would like to let ALL parent scope data to trickle down transparently.
None: simple, read-only directives
I don't really need to mess with scope methods or variables. I'm probably doing something that doesn't have to do with scopes (such as displaying simple jQuery plugins, validation, etc).
Notes
You should not let ngModel or other things directly impact your decision. You can circumvent odd behavior by doing things like ng-model=$parent.myVal (child) or ngModel: '=' (isolate).
Isolate + transclude will restore all normal behavior to sibling directives and returns to the parent scope, so don't let that affect your judgement either.
Don't mess with the scope on none because it's like putting data on scope for the bottom half of the DOM but not the top half which makes 0 sense.
Pay attention to directive priorities (don't have concrete examples of how this can affect things)
Inject services or use controllers to communicate across directives with any scope type. You can also do require: '^ngModel' to look in parent elements.
After writing a lot of directives, I've decided to use less isolated scope. Even though it is cool and you encapsulate the data and be sure not to leak data to the parent scope, it severely limits the amount of directives you can use together. So,
If the directive you're going to write is going to behave entirely on its own and you are not going to share it with other directives, go for isolated scope. (like a component you can just plug it in, with not much customization for the end developer) (it gets very trickier when you try to write sub-elements which have directives within)
If the directive you're going to write is going to just make dom manipulations which has needs no internal state of scope, or explicit scope alterations (mostly very simple things); go for no new scope. (such as ngShow, ngMouseHover, ngClick, ngRepeat)
If the directive you're going to write needs to change some elements in parent scope, but also needs to handle some internal state, go for new child scope. (such as ngController)
Be sure to check out the source code for directives: https://github.com/angular/angular.js/tree/master/src/ng/directive
It greatly helps on how to think about them
Just thought I'd add my current understanding and how it relates to other JS concepts.
Default (e.g. not declared or scope: false)
This is philosophically equivalent to using global variables. Your directive can access everything in the parent controller but it is also affecting them and being affected at the same time.
scope:{}
This is like a module, anything it wants to use needs to be passed in explicitly. If EVERY directive you use is an isolate scope it can be the equivalent of making EVERY JS file you write its own module with a lot of overhead in injecting all the dependencies.
scope: child
This is the middle ground between global variables and explicit passthrough. It's similar to javascript's prototype chain and just extends you a copy of the parent scope. If you create an isolate scope and pass in every attribute and function of the parent scope it is functionally equivalent to this.
The key is that ANY directive can be written ANY way. The different scope declarations are just there to help you organize. You can make everything a module, or you can just use all global variables and be very careful. For ease of maintenance though it's preferable to modularalize your logic into logically coherent parts.There is a balance between an open meadow and a closed jail-house. The reason this is tricky I believe is that when people learn about this they think they are learning about how directives work but actually they are learning about code/logic organization.
Another thing that helped me figure out how directives work is learning about ngInclude. ngInclude helps you include html partials. When I first started using directives I found that you could use it's template option to reduce your code but I wasn't really attaching any logic.
Of course between angular's directives and the work of the angular-ui team I haven't yet had to create my own directive that does anything substantial so my view on this may be completely wrong.
I concur with Umur. In theory, isolated scopes sound wonderful and "portable," but in building my app to involve non-trivial functionality I came across the need to incorporate several directives (some nested inside others or adding attributes to them) in order to fully write in my own HTML, which is the purpose of a Domain Specific Language.
In the end, it's too weird to have to pass every global or shared value down the chain with multiple attributes on each DOM invocation of a directive (as is required with isolate scope). It just looks dumb to repeatedly write all that in the DOM and it feels inefficient, even if these are shared objects. It also unnecessarily complicates the directive declarations. The workaround of using $parent to "reach up" and grab values from the directive HTML seems like Very Bad Form.
I, too, wound up changing my app to have mostly child scope directives with very few isolates -- only those which don't need to access ANYTHING from the parent other than what they can be passed through simple, non-repetitive attributes.
Having dreamed the dream of Domain Specific Languages for decades before there was such a thing, I'm elated that AngularJS provides this option and I know that, as more devs work in this area, we're going to see some very cool apps that are also easy for their architects to write, expand, and debug.
-- D