feat(mdCompiler): support `preAssignBindingsEnabled()`

[gkalpak]

Actual Behavior:

• What is the issue? * mdCompiler always pre-assigns bindings on controller instances.
• What is the expected behavior? mdCompiler should respect the preAssignBindingsEnabled() flag (if present).
  This new configuration option was introduced with feat($compile): add preAssignBindings flag angular.js#15095. Although it is not directly related to mdCompiler, people might expect the option to be respected by ngMaterial as well (possibly as a result of not realizing ngMaterial uses its own compiler for certain things).

Angular Versions: *

• Angular Version: 1.5.9+, 1.6.+
• Angular Material Version: All

[gkalpak]

For reference, here is how we fixed the same issue for ngMock/$controller: angular@7d9a791

And while you are at it, you might want to fix support for classes and controllers that return a value from their constructor (demo of the issue), by re-assigning the bindings if ctrl !== invokeCtrl.instance here.

[mgol]

Doing this right would also mean implementing support for this flag (& lifecycle hooks) to dialog controllers. But that, in turn, would be better achieved by dialogs just using real components instead of manually passing a controller and a template.

[gkalpak]

I agree that it is much better to leverage the core $compile service as much as possible (for feature parity, consistency and DRYness) and using components for dialogs (via templates) is an indirect way to achieve that (so totally recommended if you ask me).

In the meantime though, taking the value of preAssignBindingsEnabled into account requires very little effort, so I don't see why not.

(Note that although support for lifecycle hooks would be nice-to-have, it is not strictly necessary for this. That said, the $onInit() would be very helpful indeed.)

[mgol]

To take preAssignBindingsEnabled into account you need to at least implement the $onInit hook. Otherwise there's no place in the controller where referencing the bindings is safe.

[gkalpak]

It is safe referencing them in templates and in methods registered as event handlers or invoked via the template. I admit that in order to unlock the full potential you need the $onInit hook, but you can for example support some usecases, such as setting default values in the controller constructor and letting them be overwritten by bindings.

[mgol]

@gkalpak The issue I have with this partial approach is that I'd like to have preAssignBindingsEnabled set to false in Angular but I still need to apply initialization logic to my bindings in dialog controllers. I can work with any of the following scenarios:

1. Material doesn't respect the flag
2. Material respects the flag & implements $onInit

In the second, I'll write the logic in $onInit as in the regular components. In the first, I'll just remember I have to write it in a constructor in dialogs.

If Material respected the flag but didn't implement $onInit, I'm blocked. Hence, as long as there's no way to flip the flag only for some components, I think implementing taking this flag into account should be blocked on implementing $onInit.

[mgol]

BTW, if this issue is about Material following the flag as set in Angular then I think it requires a breaking change so can't arrive before 1.2.0. Unless the behavior was itself hidden behind a Material flag.

[gkalpak]

Hence, as long as there's no way to flip the flag only for some components, I think implementing taking this flag into account should be blocked on implementing $onInit.

Fair point.

BTW, if this issue is about Material following the flag as set in Angular then I think it requires a breaking change.

I am not sure I agree. The way I think about it, the fact that ngMaterial is manually instantiating the Dialog controllers and wiring everything together is an implementation detail. From the developer's point of view, the dialog configuration looks like a regular DDO on steroids (because of the extra features). The fact that ngMaterial tries to replicate the behavior of regular directives (e.g. by pre-assigning bindings on the controller instance), for example, reinforces this impression.

In that sense, I would consider it a breaking change in Angular not in ngMaterial. Although admittedly, this is one of those foggy, undocumented areas where things aren't black and white 😃