Re: Om and core.async: Necessary together?
Thanks for the clarification, that helps a lot. And I agree you wouldn't expose channels in the public API for a component, that's definitely an implementation detail. I have more ideas/questions on the topic, but I don't want to hijack this thread, and I probably need to spend some more hammock time before I propose anything. Thanks again. -- 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.
Re: Om and core.async: Necessary together?
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 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 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
Re: Om and core.async: Necessary together?
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 > > 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
Re: Om and core.async: Necessary together?
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 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 < > brendanstromber...@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 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.
Re: Om and core.async: Necessary together?
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 < brendanstromber...@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 > > 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 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.
Re: Om and core.async: Necessary together?
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 > > > 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 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.
Re: Om and core.async: Necessary together?
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 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 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.
Om and core.async: Necessary together?
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 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.
