@David--that's awesome; the last time I clicked into the "Advanced Tutorial" I got what amounted to "coming soon" text.
"In many applications you have some component several levels deep in the render tree. The question is, how do we get data to this component without having to pass data to everyone in between the root of the application and where the component actually lives?" Yeah, that's basically a direct summation of what my concerns were. :) I'll dig into this today--thanks! On Friday, October 17, 2014 8:28:27 AM UTC-7, David Nolen wrote: > 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.
