delegating function calls between controllers in angularjs - angularjs

Question

Following situation:
There are two directives with controllers (A & B) - which are both children of another controller (C).
Controller A manages stuff for its model.
Now Controller C needs to call functions from Controller A to modify some stuff. And furthermore it needs access to some properties and read them.
I'm uncertain on what the right approach to communication is. And wheter to stick to one approach.
Following up is a small code example to illustrate the problem in a more concrete way.
First off there is a provider where components can register themselfes.
angular.module('components', [])
.provider('db', function(){
this.registerComponent = function(name, component){
...
}
});
Now there is a directive & a Controller (A) which displays concrete components.
angular.module('components')
.directive('componentDashboard', function(){
return {
scope:{
concreteComponents: '='
},
controller: function($scope){
$scope.model = concreteComponents;
$scope.model.someImportantProp = "foo";
$scope.addComponent = function(c){...}
}
}
})
That is basically the setup. The directive componentDashboard can display a set of components which registered to the db provider.
There are controller functions (A) like addComponent which needs to be called from outside of the controller (Controller B wants to call this). Furthermore Controller B wants to access different properties and so on.
Whats the preferred way of doing this?
At the moment there are these paradigmas used:
1) Factory hack ?! Basically there is a factory with some functions:
angular.module('components')
.factory('componentStub', function($log){
return {
addComponent : function(c){
$log.error("stub not overwritten");
}
}
})
These functions are now overwritten by the component's directive:
angular.module('components')
.directive('componentDashboard', function(componentStub){
return {
scope:{
concreteComponents: '='
},
controller: function($scope){
$scope.model = concreteComponents;
$scope.model.someImportantProp = "foo";
$scope.addComponent = function(c){...}
componentStub.addComponent = function(c){
$scope.addComponent(c);
}
}
}
})
2) event based
angular.module('components')
.factory('notificationCenter', function(){
return {
registerToNotification: function(id, not, cb){..}
}
})
.directive('componentDashboard', function(notificationCenter){
return {
scope:{
concreteComponents: '='
},
controller: function($scope){
$scope.model = concreteComponents;
$scope.model.someImportantProp = "foo";
$scope.addComponent = function(c){...}
notificationCenter.registerToNotification("foo", "doAddComponent", function(c){
$scope.addComponent(c)
}
}
}
})
At the moment there are both approaches used. There are some advantages of using this. Its developed fast, there are just few depencencies or restrictions to it. And it works.
But! I'm unsure about whether it is a good approach. I'm experiencing kinda bad maintenance on that and the more complex it gets(lets say some components can be added and some not -> states) the more it feels like not the right approach.
How should this problem be approached ?
Sorry for the long question, thanks in advice
Schemii

Answer 1

There are multiple methods how you can solve this. Ensuring that it is maintainable comes down to isolation: let the different components work on their own without dependencies of each other.
Combine any of the following tactics (from easiest to harder to implement):
Let the parent view pass the model (or parts of it) to child directives (via attributes)
$watch for changes in the main controller/directive to react on changes.
Let the parent controller/directive register ($scope.$on) callbacks to certain events. Childs can $emit events upwards to their parents. Parents can $broadcast events downwards to their children.
Let the child directive expose a callback/expression (see the & prefix in the isolate scope options)
Share a (singleton) service instance that will handle model changes. Inject this service where needed. Since this is a singleton, you'll have to make sure that you'll cleanup callbacks whenever a scope is destroyed otherwise you'll leak memory.
Hope this helps.
Cheers.