(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.
