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 clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
