The "controller as" syntax was added to AngularJS 1.2. This syntax abstracts the use of $scope
in controllers, simplifying the syntax of your controllers.
John Lindquist: If you look closely in the 1.1.5 release of Angular, you'll notice in the change log support for "controller as" syntax. Now it's a very minor, short sentence right there which can have actually a major impact on the way that you think about Angular. So let's start working with the "controller as" syntax.
It's worth noting that this is an experimental feature and it may be removed at later times. But I personally hope they keep it in. That's just my opinion.
So if we add a controller and we'll just say "room controller as room." Then we'll set up a room controller. So that controller, room controller, and then we can say this open door as a function. We'll expose this to the html and this alert creak.
Now that we are using room controller as room, we can actually access the controller just by typing room. So if we have a button and we just say ng-click, we say "room" meaning the room controller, we can say "open door." When you click this, [inaudible 01:25] text will open. So if I come over here and click this, the room will creak. That's because it's calling this open door off of the room controller.
Now, the most important thing is to notice what is not there. You do not see a scope injected into the room controller. That means that even if you are going to expose something like a button title, I'm a button, and we hop back over to index file and we do "room.button title," you can see that we updated a button title to I'm a button.
Again, we've never used a scope to communicate that over the html. So anything you communicate to the html can potentially be put on the controller itself which helps a lot with languages like coffee script and type script and [inaudible 02:32] six where you can define classes and expose functions and things like that and use those as your controllers. So this syntax right here basically changes the entire way you think about providing things to the html.
Now, the scope is still insanely useful, of course, for things like watchers and dollar apply and all the other things that scope manages, scope inheritance included. It's just that using this syntax "as room" you are now accepting this paradigm where you are exposing things to html through the controller.
Now, the other thing to mention is that this was achievable before. I think I even did the video. I'm 99 percent sure I did a video about it where an alternative way of returning the controller where you would inject a scope and you would say room equals this. That's basically what it would look like. It's just that now, this is kind of a built-in feature into Angular and version 1.1.5 which may stick around.
The last benefit I want to mention as you start getting nested controllers. We'll kind of mock up an example here. We'll say ng-controller and other controller as other. Let's capitalize that. As we start getting nested controllers, it's very easy to see where the inheritance is coming from.
If I say "room foo" and "other foo" you know where foo is coming from, whether it's coming from the other or from the room. There is that definite separation. Whereas, if we're using scopes, the scope inheritance, you wouldn't know exactly what's going on. Similarly, this paradigm or this way of thinking about it forces that dot which I've talked about in other videos.
So you have to use the dot to access this. You are never going to be using a single primitive value inside of here which would be overwritten and ng-repeat other examples we've talked about.
Anyway, so that's what this controller as syntax is and how it can potentially change the way you interact between Angular and your html. Definitely give the Angular team feedback through whatever venue you can contact them through, whether mailing lists or meet ups or Twitter or whatever. I think it's a very promising change. But if you run into issues, definitely let them know.
Member comments are a way for members to communicate, interact, and ask questions about a lesson.
The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io
Be on-Topic
Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.
Avoid meta-discussion
Code Problems?
Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context
Details and Context
Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!