Not sure if this use case might be helpful, but you can check out chapter 6 
of the rough draft of my book on Leanpub 
<https://leanpub.com/web-component-development-with-angularjs> (it's free 
for now).  In this situation the container component is a navigation bar, 
and child components are dropdown menus.  When one dropdown component is 
expanded, all of the other dropdowns need to know to contract.  I'm using a 
service (mostly the same as AngularUI) to track "open" state  and handle 
the communication between dropdowns in a decoupled fashion because a 
dropdown component can be re-used anywhere on the page (inside or outside 
the container). So not using pub-sub in this case, but if your child 
directives will only ever exist in that container then I'd definitely use 
events with the container as the mediator.

https://leanpub.com/web-component-development-with-angularjs


On Tuesday, August 26, 2014 9:08:24 AM UTC-7, Naveen Kohli wrote:
>
> Thanks for your input Eric. I will explain it a little further. Child 
> directive exposes common set of interfaces for communications. Lets say 
> that Child has an action "refresh". This child does not do anything by 
> itself. It acts as container for some other directive(s). 
>
> Parent
>  - Child (1) {refresh}
>    - DoFooDirective
>    - DoBarDirective
>  - Child (2) {refresh}
>   - DoBazDirective
>
> Lets say that DoFoo has done something. It needs to tell Child(2) that it 
> needs to refresh the directives that it is housing. That refresh means 
> different things to each of these directives.
>
> I hope this explains the structure little better.
>
>
> On Tue, Aug 26, 2014 at 11:52 AM, Eric Eslinger <[email protected] 
> <javascript:>> wrote:
>
>> Each child directive has the same set of actions, but does stuff on 
>> different data? As in, they all have a doStuff() that manipulates their 
>> unique data, but the data they contain is different.
>>
>> In that case, this smells kind of like a situation where you'd want to 
>> have a more robust model layer. If the directives are presenting a view, 
>> you could put all the relevant data in a model that gets pushed into the 
>> view. <child ng-repeat="item in items" item="item">, and then define your 
>> functions on the item objects. Models could have an arbitrary relationship 
>> outside of the event doodad.
>>
>>
>>
>>
>> On Tue, Aug 26, 2014 at 8:29 AM, Naveen Kohli <[email protected] 
>> <javascript:>> wrote:
>>
>>> I am trying to set up a framework that following structure.
>>> Parent Container (It is a directive)
>>>  - Child (Its a directive)
>>>  - Child
>>>  - Child
>>>  .... so on
>>>
>>> Parent contains collection of same "Child" directive. Each child 
>>> directive can be identified by a unique id.
>>>
>>> Each instance of child directive performs unique actions. At some point 
>>> one child has to communicate with other child to do signal it to do 
>>> something in response to some action it has done.
>>> There is one clean options I can see for this communication.
>>> Use pub/sub model through a factory. Child can "emit" message to parent 
>>> and then parent "broadcasts" message with unique id of child that has to 
>>> take action.
>>>
>>> Is there some other better to handle this kind of scenario?
>>>
>>> No, I don't have plunker at the moment for this use case. I am just 
>>> putting some initial design in place.
>>>
>>> Thanks
>>>
>>> -- 
>>> 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] <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.
>>
>
>
>
> -- 
> Naveen K Kohli
> http://www.netomatix.com 
>

-- 
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.

Reply via email to