Sharing some links to [probably] close out the thread:
- Naming the default directive controller: https://github.com/angular/angular.js/issues/13664 - 1.5 changelog *$component* section: https://github.com/angular/angular.js/blob/master/CHANGELOG.md#breaking-changes-3 - Pete Bacon Darwin discussing 1.5 on AiA (audio) https://devchat.tv/adventures-in-angular/081-aia-angular-1-5-with-peter-bacon-darwin On Saturday, March 5, 2016 at 2:18:01 AM UTC-6, Sander Elias wrote: > > Hi Danny, > > >> *vm* ≈ *$ctrl* : True that *$* is generally a *loaded* prefix. I want to >> respect that, but I also want to be consistent for the mental context >> switching reason you hit on. Either by replacing my usage of *vm* as a >> namespace in templates or to continue using the controllerAs: 'vm' >> convention in components. What's your strategy? >> > Well, If my controller has no footprint inside the template I still prefer > vm. But lately I find myself switching to the directives tag-name more > often. Using the same name in all contexts feels much better to me. > > >> > *$onInit* ≈ constructor : Different events in the ctrl lifecycle for >> sure. In truth, snuck it in b/c it was a shiny new thing i wanted to play >> with in a plunk. Haven't >> > done much to grok it yet. But I can't figure a legit use case for it >> outside context of a component or directive controller. >> > Ah, well, there are a few, but they usually are only needed when you have > parent/child directives, and you need them to interact. Not the everyday > cup of tea. > > >> >> *angular.extend()* : mos def only in constructor and always immediately. >> I personally just find defining my instance props in a block to be good >> ergonomics. Maybe an artifact from my PHP days... but it is nice to have a >> regular place to eye-scan for that stuff. RE: runtime overrides... isn't >> that just javascript tho? Other than by using something like >> *Object.freeze()*, I think that risk is always there. >> > Runtime overrides are a real problem. using the extend on self put's it > out of your control completely. If you assign the properties by hand(or > another method that protect against it), it is much less of an issue. It > might never happen, but if it does, it's a really hard to trace issue. > (imagine a DB with 1 record having a conflicting property!) > > Regards > Sander > -- 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 https://groups.google.com/group/angular. For more options, visit https://groups.google.com/d/optout.
