David, This seems to be a different take on things than you proposed in your series of CSP articles last summer. I'm not saying that is a bad thing - if an idea doesn't pan out, it needs to be scrapped (and most of us cling to bad ideas longer than we should). I'm just curious why the change of heart (if that is the case, maybe I'm just misunderstanding you). You've mentioned reusability a couple of times, but I just don't see how the Om approach improves that over the architecture you described in those articles.
What attracted me to the React approach initially was how well it seemed to fit in with CSP. The idea of separate coordinated processes manipulating the application state, while the UI representation is just a function of that state (i.e. a pure transformation from the app state to a DOM, or virtual DOM in React's case) is very appealing. I know things are usually uglier in practice, and you have far more experience with this stuff than I do, so maybe you have just hit enough ugly parts to rethink the approach (if so, please share)? I thought I had figured out the missing piece to my comprehension when I read one of your posts on the Clojurescript group the other day, where you talked about Om components that don't render. I didn't even know that was possible before you mentioned it, and then the lightbulb came on and I started thinking about how to adapt your CSP examples in that context. It seems like you could have processes like a highlighter or selector that are implemented as non-rendering Om components and they could wrap and compose with other components. I was anxious to try that out on my current project, but I've been tied up on Datomic stuff all week and didn't get the chance yet. But after reading this post, I'm not so sure about that now. I know you've been thinking through some of the reusability issues over the last week, so maybe I just need to wait until you write up your ideas. I really want to figure this out and use it on a non-trivial real-world project (the one I mentioned above). So if you need a lab rat for some of these ideas... On Wednesday, April 9, 2014 6:57:50 PM UTC-5, David Nolen wrote: > > Also don't use a channel unless you actually need complex coordination. I > would always default to a callback first. > > David > > > On Wed, Apr 9, 2014 at 7:56 PM, David Nolen <dnolen...@gmail.com<javascript:> > > wrote: > >> Reusable components - use callbacks >> Application components (non-reusable or less re-usable) - use channels >> >> David >> >> >> On Wed, Apr 9, 2014 at 7:53 PM, Brendan Stromberger < >> brendanst...@gmail.com <javascript:>> wrote: >> >>> How can one build up the intuition to know, in what situation, whether >>> it would be more beneficial to use callbacks or channels? Are there >>> 'rules-of-thumb' that I could follow until that intuition is established? >>> >>> >>> On Wednesday, April 9, 2014 8:40:19 AM UTC-7, David Nolen wrote: >>> >>>> It's mostly for demonstration purposes, but I think it will be a common >>>> pattern when more complex coordination is required. I think components >>>> should probably communicate via callbacks and applications can glue things >>>> together with core.async if it's beneficial. >>>> >>>> David >>>> >>>> >>>> On Wed, Apr 9, 2014 at 10:54 AM, Kendall Buchanan < >>>> ken...@teachbanzai.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> I have a question about Om's "Basic Tutorial", and perhaps >>>>> core.async's role generally: >>>>> >>>>> The example given in the section, "Intercomponent Communication", uses >>>>> core.async for communication between two components. Is this necessary? >>>>> Or, >>>>> is it demonstration? It seems in testing that I can even more easily pass >>>>> functions between components as I might a channel, but without go loops? >>>>> >>>>> I've used React.js to some extent and obviously it lacks >>>>> Clojurescripts asynchronous fanciness. Where might core.async excel in Om? >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Clojure" group. >>>>> To post to this group, send email to clo...@googlegroups.com >>>>> >>>>> Note that posts from new members are moderated - please be patient >>>>> with your first post. >>>>> To unsubscribe from this group, send email to >>>>> clojure+u...@googlegroups.com >>>>> >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/clojure?hl=en >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Clojure" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to clojure+u...@googlegroups.com. >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com<javascript:> >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com <javascript:> >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+u...@googlegroups.com <javascript:>. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
