A few thoughts, though I’m sure others will have more:
-
Om requires your entire React render tree’s data to be stored in a
single atom, but you can have as many render trees as you’d like on a page,
each with its own atom of state. It’s more common to just use one, but more
than one is an option, if it makes sense for you.
-
In Om, state like showing and hiding a tab is sometimes stored in the
application state, and sometimes stored in the component’s local state.
That’s a matter of preference. As far as I know there’s no big rule of
thumb for when one is better than the other; they each have some subtle
advantages and disadvantages.
-
Reagent is more than just a thin veneer over React. It does quite a bit
of work, just as Om does. This is subjective, but Reagent feels more easy
than simple to me. Sometimes, that’s what you want; sometimes it’s not.
But: I’ve barely touched Reagent myself, so take that with a large grain of
salt. I’d love to hear a response from someone actually working with
Reagent.
-
There *is* a React wrapper that’s mostly a thin veneer: Quiescent
<https://github.com/levand/quiescent>. Quiescent, to me, is at the
simple end of the simple-easy spectrum. Unlike Om or Reagent, it doesn’t
manage your rendering for you; you store your state where you will and tell
it to render the tree when you think it should (which is how React itself
works).
I have a blog post
<http://blog.peeja.com/blog/2014/10/01/react-four-ways-how-to-use-react-in-clojurescript/>
that goes into some more detail with links to examples, if you’re curious.
Hooking up URL routing to any of these has had my head spinning as well.
I’d love to hear what other people are doing for that too.
Peter
On Thu, Oct 23, 2014 at 9:04 AM, Colin Yates <colin.ya...@gmail.com> 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.
>
--
Visuals: http://youtube.com/peeja
Words: http://blog.peeja.com/
Conversation: (603) 548-1203
--
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.
