Thanks for your reply. Makes sense. I wasn't thinking of the case of multiple controllers, as much, in which case isolation is better.
On 6 May 2014 03:12, Кошелев Иван <[email protected]> wrote: > Having controller be the scope would bring a lot of problems into the > picture - you would only be able to use inheritance rather then composition > to construct you scope objects, which would essentially cripple a > dynamically typed language like JS. > i dont think inheritance is necessarily bad. as a (possibly terrible) example we can hack it to inherit the scope: http://plnkr.co/edit/9zc6yWHid4mJSwzUGUOe?p=preview. This would lead to some serious naming clashes however - although, same goes for controllerAs however - just to a lesser degree. (if your 'as' var clashes) Right now Angular mostly relies on mixins type of composition (each > controller adds methods and properties directly to the scope object). > "Controller as" gives you a shortcut to more classical composition > (controller encapsulates all the needed functionality and becomes a well > isolated part of the scope object). To understand why this is better - > consider this two situations: > 1.) You have an element like <div ng-controller="Ctrl1" ng-directive1 > ng-directive2 >...</div>, where both directives have controllers of their > own. No single controller can become the whole scope. You can either have > them all mix into the same scope, or, as i prefer, attach themselves to it. > The second way is just much cleaner and less prone to naming collisions. > agreed. In the case if multiple controllers, it does make much more sense to isolate. This to me is the best reason for controllerAs. > 2.) Think broader about controllers then just Angular controllers. Think > of the scope as just another dependency (an optional one at that). As i > said earlier, "This allows you to reuse controllers from the world of > Angular in, say, NodeJS and bring non-angular controllers into your code > with few-to-non modifications needed. You are creating it in a way that is > more universal across all of JS, not specific to one framework." With that, > you usually also get a much cleaner Separation of Concerns. > > As for the barely referenced part - there isn't much to reference beyond > " '<div ng-controller="CountController as CountCtrl" >...</div>' roughly > the following happens '$scope.CountCtrl = new CountController(... > dependencies)' " > > yup. makes sense. Im still just annoyed by > > On Tuesday, May 6, 2014 2:26:46 AM UTC+4, tonypee wrote: >> >> Im wondering what original reasons for not having the controller *be* the >> scope were (like it originally was). Is it because of the need for scope >> inheritance? >> >> Using 'controller as' the scope is barely referenced, and so scope >> inheritance isnt useful to the developer anyway. services are used for >> inter-controller sharing anyway. If removing the inheritance simplified the >> system, then could the controller *Be* the scope again? >> >> My thinking is that, if inheritance is removed, and a tree is built using >> this.parent (for events - as is currently, and is like the DOM for example) >> then the controller could just extend a scope class. >> >> 'Controller as' is not really needed then, but could just be an attribute >> referencing *this* if you wanted that style in the view. >> >> >> >> >> >> >> >> On 24 April 2014 04:20, Кошелев Иван <[email protected]> wrote: >> >>> Vinay, I see. In TypeScrpit when you use 'class' keyword there is no way >>> to make the generated properties JS private, even if you use the 'private' >>> TS keyword. The reason for that is described here http://typescript. >>> codeplex.com/discussions/397651 . As they describe - the problem is >>> about JS inheritance overall and the fact that TS 'private' keyword behaves >>> like 'protected' keyword of languages with traditional inheritance. The >>> problem is more about prototypical inheritance, so discussing it here would >>> be of-topic, IMHO. >>> >>> In consolation, I can say I never had any problems of that sort in >>> projects with Controllers like >>> constructor(public api: ApiService, public $modalInstance: >>> ng.IModalInstance, public work: IWorkVM, public $rootScope: ng.IScope, >>> public $q: ng.IQService, public $timeout: ng.ITimeoutService) {...} >>> >>> If you have some specific case where that problem occurs, maybe you >>> could email me a description of it to koshelew at gmail com ? >>> >>> >>> On Wednesday, April 23, 2014 9:43:14 PM UTC+4, Vinay Gangoli wrote: >>>> >>>> Thanks for the reply! The examples are very clear and I especially like >>>> the handling of nested controllers. >>>> >>>> I guess my concern here is I would be able to do >>>> controller.$q.anyExposedProp from the view which I would like to prevent. >>>> Is there any way to achieve this in Typescript? >>>> >>> -- >>> 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. >>> >> >> >> >> -- >> Tony Polinelli >> >> -- Tony Polinelli -- 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.
