I really like quiescent. I don't know why it's almost never mentioned in these discussions.
On Saturday, 25 October 2014, Matt Ho <[email protected]> wrote: > We ended up with a similar path with other folks that posted. We started > with Om, but found it brought with it a lot of incidental complexity. > Switching to Reagent has been very simple and we've been very happy with > the transition. > > For us, the code is understandable quickly, feels like less of a burden to > maintain, and productivity has gone up substantially > > M > > On Thursday, October 23, 2014 6:04:31 AM UTC-7, Colin Yates wrote: > > (apologies if I have overlooked any of this in the docs, it isn't from > lack of reading, more reaching saturation point - RTFM is a perfectly good > response if it contains a link to the relevant bit :)) > > > > My use case is that I have a non-trivial single page app. Inside this > app there are a number of distinct areas, for a completely made up domain > of car rental: > > - searching for/editing/adding a new customer > > - searching for/editing/adding a car > > - assigning a car to a customer > > - receiving a car from a customer > > - removing a car due to maintenance/crash > > - various reports - top 10 customers, top 10 cars etc. > > - and so on > > > > Each functional area is pretty unrelated from the others. Inside each > functional area there are individual components that all need to talk to > each other. > > > > Is it true that om really wants to manage the entire application state > in a single atom. So we might have an atom map structured with keys > referencing each functional area {:car-search {} :patient-search {} ...}? I > understand that this isn't inefficient as components receive a cursor into > their bit of the map thus avoiding unnecessary false changes. > > > > The main app will have an expandable left panel containing the global > menu. In dom-manipulation world I would add a "collapsed" or "expanded" CSS > class which defined the appropriate widths etc. In om (or rather react) > land this is still possible I think, but is it more idiomatic to store the > expanded/collapsed flag in the application state thus causing the "panel" > component to re-render, the panel component then switching on that > "expanded?" flag? The "central" panel also needs to be resized in response > to the expansion/collapse, thus both components need to be in-sync. How is > this idiomatically handled? > > > > In the more general case, there are components that need to be > shown/hidden (tabs, validation pop-up errors etc.). In dom-manipulation > world I would set css classes to change style's visibility for example, is > this idiomatically done through flags in the application state? > > > > I am stumped as to how routing navigation fits into something like om. > Again, is it a case that the navigation handlers simply update the > application state? (You can see a theme in my thinking here!) > > > > In terms of reagent is it true to say that it is a bit less opinionated > about these things and where-as om has a very opinionated approach to > front-end state management (happening to use om), reagent is a (very nice) > wrapper to om? Not to trivialize reagent, but is is "simply" trying to > introduce clojurescript to react? > > > > Is it also true to say that whilst om wants to manage the whole > application, reagent allows you to think about disconnected bits of your > app? > > > > FWIW - reagent appeals to my pragmatic "need to get stuff done" and it > feels very un-opinionated and very lightweight. However, the more I read > about om the more it jives with me. However, I am in the pattern of "yeah, > that is how I would solve that problem", I just can't quite connect the > dots in the bigger picture. > > > > It is also worth saying that there are no losers here, I am sure I will > be delighted using either om or reagent. > > > > I think that is sufficient for now - thanks for reading, and thanks even > more for responding :). > > -- > 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] <javascript:;>. > To post to this group, send email to [email protected] > <javascript:;>. > 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.
