This is a good pattern that will help in a lot of situations, but I don't think it will catch everything.
Unless I am missing something (very possible - I'm only just getting to grips with this stuff) this relies on the parent and children knowing the topic to pub/sub on. So for example say I have a list of a 1000 clients and each of these clients has a sub component that let's you enter a new invoice to raise for the client. When that invoice is entered the sub component needs to inform the parent that it needs to update it's total. To push that info to the correct client the sub component would need an ID value of the client that needs updating. This ID would still need to be passed down the component tree. If an ID is being passed down, you may as well just pass a channel down instead. What would be awesome would be if you could specify some kind of local-shared data that was only available to a component and all its children. As a learning exercise I have been trying to hack something like this myself into Om but so far have failed miserably. It has been an enlightening experience though. <div>-------- Original message --------</div><div>From: David Nolen <[email protected]> </div><div>Date:17/10/2014 4:28 PM (GMT+00:00) </div><div>To: [email protected] </div><div>Subject: Re: [ClojureScript] Om - Passing channels down through hierarchy </div><div> </div>This is not entirely true. core.async supports pub/sub on topics making one global publish and one global notification channel a good strategy. I recently wrote about this: https://github.com/swannodette/om/wiki/Advanced-Tutorial David On Fri, Oct 17, 2014 at 11:11 AM, Stephen Wakely <[email protected]> wrote: > This would only work if there was only one global channel needed. > > It wouldn't work if you needed separate channels for different branches of > the tree - say if you had multiple items in a list and each of those items > needed a channel to pass to sub-components. > > On 17 October 2014 16:02, Jamie Orchard-Hays <[email protected]> wrote: >> >> I have a base component that creates a channel and then I pass the channel >> via the :opts key-value to its children. However, another user posted >> recently that the :shared data could be modified as it is passed down the >> hierarchy. It seems to me this would be a DRYer way to pass the channel down >> to descendants as you would not have to explicitly pass the channel in :opts >> at each descendant. >> >> Thoughts? >> >> Cheers, >> >> Jamie >> >> On Oct 16, 2014, at 11:21 PM, Brian Crescimanno >> <[email protected]> wrote: >> >> > Hi everyone, >> > >> > I've been playing with Om the past few days both due to my own interest >> > in Om itself as well as my long-standing desire to learn ClojureScript. >> > With >> > that in mind, I'm relatively new to both. >> > >> > After following the Om "Basic Tutorial" I set about creating my own demo >> > app (a drag-and-drop rank-voting UI). One of the concepts I saw introduced >> > in the tutorial was using Core.async channels to deal with events and I >> > initially copied that paradigm into my app. Within a few minutes, I was >> > realizing that I must be going down an anti-pattern path. >> > >> > One of the things I like best about Om so far is that it seems to >> > encourage me to always be thinking about pieces of functionality as actual >> > "components" rather than the traditional MVC paradigm. As I went along, I >> > realized I was passing a channel down (via :init-state) through 4+ levels >> > of >> > component nesting. Any time I have to write the same block of code more >> > than twice, I question it. >> > >> > After thinking on it a while, I assume it's probably better to pass the >> > right cursor and modify the cursor directly from the interior components. >> > In my case, my hierarchy looked like: >> > >> > items-view >> > item-view >> > item-detail >> > vote-button >> > >> > ...with the bottom 3 all sharing the same cursor. >> > >> > That said, I wanted to ask around to folks using Om what the "idiomatic" >> > approach is. I quickly started to think that the Basic Tutorial was likely >> > introducing Core.async to help people get familiar with ClojureScript and >> > not anticipating the anti-pattern it was establishing. But, since I don't >> > know idiomatic approaches yet; I thought I would ask if there was something >> > I'm missing in terms of using async channels more effectively. >> > >> > Thanks for the advice! >> > >> > Brian >> > >> > -- >> > Note that posts from new members are moderated - please be patient with >> > your first post. >> > --- >> > You received this message because you are subscribed to the Google >> > Groups "ClojureScript" 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/clojurescript. >> >> -- >> Note that posts from new members are moderated - please be patient with >> your first post. >> --- >> You received this message because you are subscribed to the Google Groups >> "ClojureScript" 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/clojurescript. > > > -- > Note that posts from new members are moderated - please be patient with your > first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" 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/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" 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/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" 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/clojurescript.
