feat(directive): Add ability to inject required controllers into the controller function

quick overview
You have the directives A, B and C
B requires A,
C requires B

The methods in C need to call methods in the controller of B.
The methods in the controller of B need call methods in the controller of A.

The controller of B cannot know the controller of A because it can only be passed into the link-function of B.

more details
http://stackoverflow.com/questions/21231294/angularjs-inject-required-directive-controller-into-the-controller-instead-of-t/21231428

Actually there is a workaround that is too complicated for such an easy problem.

Even the ngModelController does use another workaround with a feature that seems to be undocumented: the binding of directive controllers to the directive-elements data property:

angular.js/src/ng/directive/input.js

Line 969 in 5adea0b

var parentForm = $element.inheritedData('$formController') || nullFormCtrl,

[thorn0]

This issue should be reconsidered. Now that we have bindToController, it's inconsistent and not clear why required controllers are accessible in the link function, but not in the controller constructor. If somebody wants to create directives the controllers of which interact with each other, they have to initialize the controller with a special call from the link function now.

m.directive('childComponent', function() {
  return {
    require: ['childComponent', '^parentComponent'],
    controller: function($scope) {
      this.init = function(parentComponent) {
        this.parentComponent = parentComponent;
        // ...
      };
    },
    link: function(scope, el, attrs, ctrls) {
      var childComponent = ctrls[0],
        parentComponent = ctrls[1];
      childComponent.init(parentComponent);
    },
    // ...
  };
});

Why can't this look like this?

m.directive('childComponent', function() {
  return {
    require: '^parentComponent',
    controller: function($scope, parentComponent) {
      this.parentComponent = parentComponent;
      // ...
    },
    // ...
  };
});

[shahata]

In general I agree that this is inconvenient, but I think that the main issue with passing the required controller in the controller constructor is that then you will not be able to have symbiotic directive (a require b and b require a - example: http://plnkr.co/edit/RrBKdrExc4CaYIqyXJhq?p=preview). You will have circular dependency instead, and I don't think we want to break this kind of directives.

[thorn0]

It's possible not to break the directives of such kind. Because in JS, it's possible to create objects before calling their constructors, and that's how actually bindToController is implemented.

[shahata]

Still constructor of controller a will not be able to invoke stuff that are defined in constructor of directive b if it didn't get constructed yet, which is pretty confusing.

[thorn0]

That's true, however such symbiotic directives look like an edge case and not the best design choice, don't they? And if you decide to create alike symbiotic services that use each other, it will look confusing enough as well. The DI system won't allow you to do this without a workaround. So can this really be a stopper for this feature?

[johnlindquist]

I think a "resolve", which works similar to how routing handles controllers, makes more sense.

For example, "require" uses $element.controller('directiveName') to look up controllers of other directives.

You can simply inject $element into your controller and do it yourself:

pseudo non-working off-the-cuff code below:

function FooCtrl($element){
var otherCtrl = $element.controller('other');
}

but I'd rather have a resolve to remove the $element dependency (for testing, etc)

.directive('foo', function(){
  return {
    resolve: {
      other: function($element){
        return $element.controller('other')
      }
    },
    controller: 'FooCtrl as foo'
    }
  })

//other found on resolve
.controller('FooCtrl', function(other){
  other.doStuff()
}

[kentcdodds]

Hmmm... I sort of like the idea of resolve in directives. I'm torn because the DDO is so complex already, adding resolve could make it worse. Also, what does that do to the visibility of the api for a directive? If there are some things that are resolved into the controller for a directive then you can't just look at the html and know what the api to the directive is anymore, you have to know what the dependencies in the resolve are as well which may not be an issue, but I think it could. Also, if resolve is asynchronous, then what does the DOM look like while it's being resolved? If it's not, then it leads to an even further confusing api.

Those are concerns, not solutions. I think a good solution to this would be to simply add the controller to locals when the controller is instantiated via the controller name as @thorn0 recommended. I feel like that is a reasonable api and it doesn't complicate the DDO further.

Still haven't totally thrown out the value of resolve though. Would be interested to hear responses to the concerns I mentioned.