Hi,
I haven't followed this topic in quite a while and am not as active on
those groups as I was before.
It really is a stroke of luck that I saw your message today :P
I don't quite remember the initial problematic, the what and the why, etc.
Could you maybe explain what you're trying to achieve?
Since the last few years, I found that the community as a whole "evolved"
quite a bit about best practices, how to approach those kind of problems,
etc
If I may suggest, you might want to update your understanding/knowledge of
angular to follow the same path; The current direction being what we could
call the "Component Approach" which is closer to where
WebComponents/Polymer/React/Angular 2 are going. The big idea is to have
dumb components (directives) that receives only the data they need from
their parents and so forth. To that effect, the Flux pattern ("pioneered"
by Facebook with React) is getting more popular in that effect (but is
definitely not an absolute).
It is "now" common place to consider that using explicit $watch in your
controllers/directive might reflect a bad design, and it is recommended to
avoid them whenever possible, granted you sometime won't have much choices
(or should I say, the effort in developing the alternative solution might
be too long/costly to go that route due to time constraints for example)
The same goes in using the $scope service,
Here's a few articles that I found useful that might shed some light (there
are many others, don't be shy to use google!):
http://busypeoples.github.io/post/thinking-in-components-angular-js/
https://www.airpair.com/angularjs/posts/component-based-angularjs-directives
http://teropa.info/blog/2014/10/24/how-ive-improved-my-angular-apps-by-banning-ng-controller.html
And John Papa's style guide for Best Practices is quite good too:
https://github.com/johnpapa/angular-styleguide
Following those idea should simplify how you're going to build your
application in the long run
I'm sorry for not providing you with a more concrete answer to your
question, but I think this will at least give you some tools to find a
better solution to it and many others you might encounter (Teach a hungry
man to fish and all that jazz?). I have to admit that part of the reason
for this answer is due to me being in a rush right now and not really
taking all the time I wish I could to give you a more proper answer
In all cases, I hope this help at least a bit!
O.
On Saturday, December 5, 2015 at 5:18:01 AM UTC-5, Kon M wrote:
>
> Really Sorry about the extremely late response to this thread.
> Olivier, originally you had recommended using events ($on / $broadcast)
> and in the new update yo have mentioned using $watch based on evolved
> understanding of Angular. Please would it be possible to elaborate why the
> $watch would be preferable to events i.e. any performance or hidden issues
> with events?
>
> Unfortunately Angular Directives don't have a "delegation" model where a
> parent controller can delegate/command a child directive to do something,
> with the guarantee that it will get done. All the currently available
> approaches are like a "best effort" where it is really up to the directive
> to do something, or not.
>
> Assuming a parent has to notify a directive of a change in the data, and
> the directive needs to update its view. Using $watch on a scope property in
> the directive seems hacky as $watch or $watchCollection can sometimes
> become inefficient if the watched property is a deeply nested array.
> One could create a separate "eventCounter" and keep incrementing it each
> time a new update is to be triggered & watch it in the directive, but again
> it doesn't feel like the right way to do it. I was of the opinion that
> events are the "best" way to achieve this, hence would appreciate your
> feedback on the above question.
>
>
> On Monday, May 27, 2013 at 4:44:23 AM UTC+5:30, Olivier Clément wrote:
>>
>> Hi
>> I don't remember quite well as it been a while indeed;
>>
>> Also, I must say my comprehension and understanding of angular has
>> evolved since too.
>>
>> If you need to apply a different set of effects by clicking different
>> buttons for instance, maybe you could just use $scope.$watch from within
>> the directive, and binding the effects you get from the server to a scope
>> property on that same directive.
>>
>> Basically you could have <directive ng-model="whatever"
>> effects="effectList">
>>
>> effectList being a property in you controller's scope or something. In
>> the directive you'd need to define this property to its scope: { effects:
>> "="}
>>
>> Hope this help!
>>
>> Le 2013-05-26 à 17:46, Corentin Kerisit <[email protected]> a écrit :
>>
>> Hello Olivier,
>>
>> I know its been a while since you had that issue but I would really love
>> to hear how you managed to control the directive from the controller.
>> I am facing such issue with a directive embeding a Three.js canvas. I
>> have a listing of effects off a webservice. I need to apply these effects
>> to the canvas on ng-click.
>>
>> I was thinking of the $on/$broadcast. Is that what you used in the end ?
>>
>> Thanks
>>
>> On Monday, November 5, 2012 7:44:54 PM UTC+1, Olivier Clément wrote:
>>>
>>> Sorry for the late response;
>>>
>>> Thank you all for your inputs; I thought about using a Service, but
>>> considering I won't ever need more than one instance of that particular
>>> directive at a time, I think it might be a bit overkill to create a service
>>> for this;
>>>
>>> I guess that the solution that would suits my needs the best would be
>>> Witold's suggestion of using $on/$broadcast
>>>
>>> I'll get into this right now;
>>>
>>> --
>>>
>>> As for more details:
>>>
>>> The directive is a D3.js Tree that display's an organisation.
>>> Outside of that directive I have a few controls that will modify the
>>> tree accordingly. I need to be able, on the click of a button or similar
>>> (outside the directive, under the same parent controller), to fire a
>>> function living in the directive and pass some parameters to it. That
>>> function will take a list of nodeID as params, and the directive will be
>>> responsible of getting JSON from a WebService and inject this data in the
>>> tree
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "AngularJS" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/angular/htKUVVNhi7A/unsubscribe?hl=en-US
>> .
>> To unsubscribe from this group and all its topics, 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?hl=en-US.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>>
--
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.
