Hi Gary, now you have mentioned it :), can you explain what you really like about it? On 25 Oct 2014 09:12, "Gary Verhaegen" <[email protected]> wrote:
> 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]. >> 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 a topic in the > Google Groups "ClojureScript" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojurescript/ozK9OJTaanQ/unsubscribe. > To unsubscribe from this group and all its topics, 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.
