That sounds very similar to the Reagent model then. I found that it was the natural approach there, since creating local component states is straight forward and it makes them readily reusable. This simply wasn't clear to me when I tried using Om and I found that the additional complexity that Om introduced was completely incidental to the applications I was writing.
On Saturday, September 13, 2014 6:32:58 AM UTC-4, Daniel Kersten wrote: > 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.
