A couple ideas off the top of my head (so they may be terrible): 1) this feels like a situation where a service object is a good idea. Make a factory or something that creates your service object and inject it in all the relevant places, instantiate it in the controller and pass it to the directive. Then use the model to track state in both places.
2) Your service object (or other methods) could return promises. So instantiate the directiveAPI and call method() on it, but know that method returns a promise that only resolves after it's fully instantiated and *then* it can do stuff. 3) Invert control by passing a method into the directive. Use the '&' scope notation to shove a method onto your directive's scope, and then have that method get called (like a callback, yo) when the funky startup on the directive is done. At that point, the rest of the controller stuff can work. 4) You could combine 3 and 2 to pass in a promise object or something like that, which could then be resolved to something in the directive and you'd have a handle on the thenable from the controller context. 5) Really, I think (1) is the right answer here. If there's actual things that have to be manipulated that the directive responds to in terms of DOM, then you need a real Model object. Have the model return promises as needed, and you can deal with proper async handling without needing to use _.defer This is what I do, I've got factories that are model constructors, models which can inflate themselves from the server using $http or from user input, and directives which manipulate the DOM based on the model values. But the controller on the parent scope doesn't have much to do with any of that, it just wires models together into directives. hope this helps and isn't just a "late in the day, not enough caffeine" braindump e On Wed, Jul 30, 2014 at 4:10 PM, Alexander Ventura < [email protected]> wrote: > Howdy y'all, > > Recently I implemented a way to communicate from a controller to a > directive using an API object (since I hate dealing with events). Allow me > to quickly demonstrate: > > module.controller('MyCtrl', function ($scope) { > $scope.directiveAPI = {}; > function doStuffWithDirective () { $scope.directiveAPI.directiveMethod > (); } > }); > > > Now in the template: > > <my-directive api="directiveAPI"></my-directive> > > In the directive: > > module.directive('myDirective', function() { > return { > scope: { api: '=' }, > link: function (scope) { > scope.api.directiveMethod = function() { ... }; > } > }; > }); > > At first, I was all smug and feeling smart about this implementation of > controller-to-directive communication, but the more I thought about it, the > more doubts I had about it being a good design. The first design kink > happened when the controller needs to do something with the directive right > as the controller is instantiated: > > module.controller('MyCtrl', function ($scope) { > $scope.directiveAPI = {}; > _.defer($scope.directiveAPI.directiveMethod()); > }); > > Notice, that I need to _.defer the execution of my code since the binding > has not happened at that time. > > Now my questions for y'all is: > > Is this a good design choice for c-to-d communication? > How can I avoid having to _.defer code execution? > > In my use case, the controller is driving the interaction with the user, > while the directive handles some very complicated DOM manipulation > ($compiles, transcludes, etc). > > -- > 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 http://groups.google.com/group/angular. > For more options, visit https://groups.google.com/d/optout. > -- 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 http://groups.google.com/group/angular. For more options, visit https://groups.google.com/d/optout.
