On Saturday, October 25, 2014 10:23:35 AM UTC+2, Colin Yates wrote: > 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.
Like Gary I also prefer quiescent. It offers a simpler programming model while still providing the speed benefits of React. Quiescent code is simpler for two reasons. I almost never bother to implement React lifecycle functions (but if I really need to, I can), and, there is no encapsulated state in the components, as Luke VanderHart illustrates in this picture: https://github.com/levand/quiescent/blob/master/doc/diagram.png Quiescent provides the most important speed benefits since (1) rendering is limited by the browser refresh rate and (2) React diffing is fast because components use shouldComponentUpdate in combination with cljs equality -- 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.
