Eric, those are some great ideas. I have heard about 1 before but have never been able to truly grok the method of doing that because of a lack of examples. Could you perhaps demonstrate with a really quick demo?
On Wednesday, July 30, 2014 4:42:33 PM UTC-7, Eric Eslinger wrote: > > 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] > <javascript:>> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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.
