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.
