Reputation: 51094
So many controllers I see have no members except for this on scope. I would imagine shared validation and business logic code never accessed directly from a binding expression need not know about the non-scope code, and only members accessed from the view actually have to be on the scope.
Could someone please clear this up for me?
Upvotes: 1
Views: 71
Reputation: 22323
$scope
is what binds the controller to the view; it is a special prototypical object that can be dynamically adjusted, making it very easy to quickly hook up to the view. However, using $scope
directly isn't the only way to handle your controllers.
Due to the prototypical nature of $scope
, and the fact that there can be multiple scopes present on a given page, it's been commonly suggested to follow the "Dot Rule" when dealing with $scope
. In essence, the dot rule simply suggests that instead of assigning primitives to $scope
, e.g. $scope.myString
, it's always preferable to "use a dot", or, assign objects to the $scope
, a la $scope.someObject.myString
.
Starting with angular 1.2, a new syntax was introduced which is designed to help with this task, the ControllerAs syntax. In essence, it allows you to assign your controller (which is already an object) directly to the $scope
, using a syntax like ng-controller = "someController as ctrl"
, and then refer to all of your bindings as properties of the controller, a la ctrl.myString
. You are now automatically using the "Dot Rule", without even having to think about it.
app.controller('someController', function () {
var ctrl = this; //self reference for this
ctrl.myString = 'Some title';
});
Note that even though we are still ultimately using $scope
, we don't actually need to provide $scope
as a dependency on the controller, and don't need to interact with it directly. However, it is still available, should we need to use an advanced service like $broadcast
.
Using the ControllerAs syntax does not eliminate $scope
, because the controller is still a property of $scope
, but it does allow you to break the coupling between your controller and scopes down a bit, and can make your HTML / controllers easier to read. having customerCtrl.name
and companyCtrl.name
is much easier to understand than having two name
properties which are only really understood in context of the surrounding elements.
Unfortunately, the vast majority of documentation and tutorials still use the $scope
object directly, and migration to the ControllerAs syntax has been slow. However, $scope
will not exist in angular 2, and the first step to migrating from 1.x to 2.x will be to convert to the ControllerAs syntax, so if you write your code this way now, it will make it trivial to migrate.
Upvotes: 1
Reputation: 406
There can be methods in controllers that are not in $scope also (May be you'll be using them as helper methods that'll be calling from $scope methods). Normally methods you wanted to call my view or variable that needed to be bind to view are kept in $scope.
Upvotes: 0
Reputation: 51481
That's right. Functions available to your expressions in the partials and directives should be assigned to the $scope object.
All your other logic does not have to be. If you're planning to reuse any logic between controllers it is better to extract it into a factory/service.
Upvotes: 3