feat($compile): allow using bindToController as object, support both new/isolate scopes

[caitp]

bindToController is now able to be specified as a convenient object notation:

bindToController: {
  text: '@text',
  obj: '=obj',
  expr: '&expr'
},
scope: {
  notBoundToCtrl: '@someOtherAttr'
}

It can also be used in conjunction with new scopes, rather than exclusively isolate scopes:

bindToController: {
  text: '@text',
  obj: '=obj',
  expr: '&expr'
},
scope: true

PING @petebacondarwin / @johnlindquist

I am not super keen on this, because it makes things much crazier than they used to be. That said:

• Currently, bindToController does not automatically imply an isolate scope --- maybe it should (I hate this though)
• It could probably do with more errors being thrown when people use it wrong
• The errors it does throw could be better
• The errors it throws are potentially breaking changes :(

Closes #10420

[googlebot]

CLAs look good, thanks!

[johnlindquist]

Why do you hate implying an isolate scope?

Also, what are the goals of "bindToController"?

For example, I'm trying to reconcile bindToController with the tabs example on the http://angularjs.org
http://jsfiddle.net/g6jb1d4b/

and using bindToController in conjunction with "require:'^tabs'" and a linking function bother me a bit. :/

(fyi, I'm working on a pull request to update the angularjs.org homepage examples)

[caitp]

The goal of it is really just to make isolate scopes work better with controllerAs --- that's all it was ever intended to do. But, there's no reason it couldn't work with new scopes too, technically.

[caitp]

Anyways, it's going to be a while before this (or something like it) lands, so it would be good to get some feedback on it, try it out and see how you like it, find bugs

[johnlindquist]

@caitp ok, thanks.

So if the goal is "scopes work better with controllerAs", have you discussed:

If a "controllerAs" is defined, imply that scope:{} bindings belong on that controller? That way you could remove bindToController completely...

[caitp]

We can't really do that, it would be a breaking change

[caitp]

Even for 1.4, it's too much of a break --- well, "too much of a break" --- it's more that controllerAs does not imply that you want bindings attached to the controller, it doesn't really make sense to do it that way even if it is a bit simpler.

Obviously, the directive api is stupidly complicated, and making it more complicated isn't helping anyone, so finding ways to simplify this would benefit everyone. But it's also a huge inconvenience due to breaking apps

[petebacondarwin]

I think the primary goal is to move even more toward the way things will work in Angular 2 where we don't use scope directly for passing data to the template but instead attach stuff to the controller that is exposed on to the template - in 1.x this is via a scope but in 2 the controller instance is the scope

[caitp]

neh, the rationale had nothing to do with v2, v2's prototype wasn't even as settled as it is now at that point.

But that's not a very important thing -- the important thing is that people generally like controllerAs and want to use it, and want to be able to put their isolate scope bindings in the controller.

[johnlindquist]

@caitp and @petebacondarwin
I would love to see your take on this famous homepage example updated with bindToController and controllerAs. I left some comments where it feels 'weird':

https://jsbin.com/xugomi/3/edit?html,js,output

[petebacondarwin]

Should this full name be more like: "controller as" identifier required to bind to controller?

[gkalpak]

If I am not mitaken, this error will also be thrown if there is bindToController: true but no controler:.... So the literals have to account for all cases (i.e. bindToController: true but no controller or no controller identifier).

[petebacondarwin]

Yep, I see that now. I was thrown by the main body of the error document, which doesn't really mention that aspect of the error at all.
I wonder if we ought to have two separate errors?

[petebacondarwin]

Apart from splitting the error message, this looks good to me. @gkalpak do you have any further comments.

[gkalpak]

👍 for separate error messages.

_{In the original PR, @caitp mentioned something about potential leaks and performance regressions.
I don't think it would be much of an issue (but I wouldn't know better); do you think it would make sense to run some benchmarks (if not already done so) ?}

Other than that it LGTM.

[caitp]

if you want to release this today, i'll split up the error message and do whatever other cleanup in about 30 minutes.

[caitp]

updated to have 2 different errors

[gkalpak]

directive definition object

[petebacondarwin]

@caitp - can you take a look at the comments here and update this PR? Thanks

[caitp]

I don't think we should be calling it "alias", because it's misleading --- so I'm just going to ignore all of the comments about renaming "identifier" to "alias"

[petebacondarwin]

@caitp - it is fine for you not to think we should not call it alias. As I explained in this comment, what we do need is consistency.

I assume that your preferred name is identifier. In which case please go through and make sure that this is used throughout. In particular remove any use of alias and label.

[frfancha]

@caitp
You say "the important thing is that people generally like controllerAs and want to use it".
I wonder why. In our experiences, directives with controller are much slower than directives with just link function and scope access, especially used under ng-repeat

[caitp]

this is ready to merge

[petebacondarwin]

Great! LGTM! Thanks @caitp. I will merge tomorrow unless you want to do it today.

[caitp]

I've got it, thanks for reviewing