I would probably still do an async autocompleter component with channels where it seems useful *internally*. I just wouldn't expose channels as an interface to users of this component. I think most of points from my CSP posts still hold even with React/Om.
David On Wed, Apr 9, 2014 at 11:57 PM, Mike Haney <txmikes...@gmail.com> wrote: > 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> 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> 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 >>>> 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 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. > -- 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.
