Dmitri, I would say that all of the donain data - that is, data that you might persist in a database - should be stored in the app state atom, but all temporary data about how to display the domain data (what page are you on, what tab is visible, is the button pressed, how much of a list is being shown, etc etc) should be in component local state.
>From what I've read, this is also how Facebook do things with their flux architecture. I started writing Om by storing everything in the one atom (I think the natural tendency is to do that) but I think you quickly realise that it's unwieldy (as you and others have asserted). Because it is! Then you transition to a model where the data you are operating on is separated from the incidental data and everything becomes much nicer and easier. On 12 Sep 2014 21:02, "Dmitri Sotnikov" <[email protected]> wrote: > 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. > -- 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.
