This might simply be my own lack of familiarity with the Om workflow. The impression I got was that most state should live in a global atom that you create cursors into and communication between components should happen using core.async channels.
On Friday, September 12, 2014 12:11:09 PM UTC-4, Jamie Orchard-Hays wrote: > I'm pondering the implications of your comments, Dmitri. In Om, I have a > single atom for my application data, but I have another atom that holds > static data I pull from the server, for example lists for drop-down select > lists. WRT local state, each Om component can have its own local state > completely separate from the app data. > > > > > > On Sep 11, 2014, at 4:31 PM, Dmitri Sotnikov wrote: > > > > > So, good news is that Sean just submitted a patch for Reagent cursors a few > > days ago. Hopefully, that will make it into the next release. > > > > > > In terms of performance I would actually expect Reagent to behave better > > than Om since it doesn't force everything into a single state atom. Reagent > > allows easily creating local states and that makes it much easier to > > control what nodes need to be recalculated. > > > > > > If I understand it correctly, the worst case for Reagent where you use a > > single state atom for everything is the normal case for Om. > > > > > > On Thursday, September 11, 2014 2:34:25 PM UTC-4, Sean Grove wrote: > > >> Bit of a sidenote, but now that the libraries are getting more mature, > >> It'd be great to see some complex-ish apps (say, Omchaya-size or larger, > >> but maybe even CircleCI's frontend https://github.com/circleci/frontend) > >> for a side-by-side comparison + speed benchmarks, to get a sense of the > >> tradeoffs as apps scale out. I'm personally curious about whether > >> Reagent's ease of use comes with a cost at some point. > > >> > > >> > > >> On Thu, Sep 11, 2014 at 8:01 AM, Jamie Orchard-Hays <[email protected]> > >> wrote: > > >> On my project, I was using data in the form of a recursive tree--an > >> editable one. I got stuck somewhere WRT to this in Reagent. (I wrote a > >> question to the original developer, but he never replied.) For my > >> purposes, Om's cursors made handling data updates trivial, so it was a big > >> win. However, I'm sure I've put a lot more man hours in the UI development > >> with Om than I would have with Reagent. > > >> > > >> > > >> > > >> So in the end, the fact that I had a recursive tree of data to work with > >> gave Om the edge, otherwise I would have used Reagent. > > >> > > >> > > >> > > >> I also had a look at Quiescent, but it was too thin a layer over React for > >> what I'm doing. > > >> > > >> > > >> > > >> Ideally, we'd have Reagent's UI simplicity combined with Om's wonderful > >> app data handling. > > >> > > >> > > >> > > >> Jamie > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> On Sep 10, 2014, at 10:11 PM, Dmitri Sotnikov <[email protected]> wrote: > > >> > > >> > > >> > > >>> I actually found Reagent's data handling to be very flexible. It' makes > >>> it easy to create local states for components as well as managing the > >>> global state using a global state atom. I'd be curious to hear what > >>> limitations others have run into and how they could be addressed. > > >> > > >>> > > >> > > >>> On Wednesday, September 10, 2014 11:40:13 AM UTC-4, Jamie Orchard-Hays > >>> wrote: > > >> > > >>>> I'm curious as well. I started with Reagent, but switched to Om/Sablono > >>>> after finding Reagent's app data handling too limited for what I needed. > >>>> The trade-off is much more to think about (complexity) when writing Om > >>>> components. > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> Jamie > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> On Sep 9, 2014, at 3:51 AM, Daniel Kersten <[email protected]> wrote: > > >> > > >>>> > > >> > > >>>> My apologies for an off topic post in this thread - we can take it off > >>>> list or to a separate thread if it needs more than a simple reply - > >>>> especially since the library looks really good! > > >> > > >>>> Sean could you write a little about why you switched away from Om? > > >> > > >>>> I'm just trying to get a better understanding of what pros and cons Om > >>>> and Reagent have and why Reagent is a better fit for your specific use > >>>> case. I've seen a few people switching lately so I'm interested in > >>>> hearing people's thoughts. > > >> > > >>>> > > >> > > >>>> On 9 Sep 2014 01:01, "Sean Corfield" <[email protected]> wrote: > > >> > > >>>> That looks great Dmitri! We've just made the switch from Om/Sablono to > >>>> Reagent so this will be very handy for us I expect. > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> Sean > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> On Sep 8, 2014, at 3:05 PM, Dmitri Sotnikov <[email protected]> wrote: > > >> > > >>>> > > >> > > >>>>> The goal of the library is to automate the process of binding form > >>>>> elements to a document represented by a map in a Reagent atom. > > >> > > >>>> > > >> > > >>>>> > > >> > > >>>> > > >> > > >>>>> https://github.com/yogthos/reagent-forms > > >> > > >>>> > > >> > > >>>>> > > >> > > >>>> > > >> > > >>>>> Feedback and contributions are welcome. :) > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> -- > > >> > > >>>> > > >> > > >>>> 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.
