Hi,
After playing a bit with om, I'm somewhat confused about state maintaining
possibilities it offers. There is global application state and local
component state. I have some doubts about using local state as it seems to
lead to troubles as soon as code grows a bit (I'm thinking about
traditional widgets, eg. data table with editing capability - somewhat
boring stuff, yet quite common in many cases). Most common approach to this
seems to be to set up some local state and then use core.async channels for
communication and updating global state asynchronousluy (go ...) blocks.
My feeling is that it creates lots of places with application state which
negates to some extent main premise of state handling by om. Do I need to
use local state at all ? Are there any alternatives ? I'm thinking about
using keyword namespacing in global state to separate concerns, for example
viewed data table row could be kept as something like :d/current-row
somewhere in global state ('d' stands for data) but when row editing starts
:e/current-row appears and is used by input fields ('e' stands for
editing). UI configuration (column descriptions etc.) would use 'u' prefix
(eg. :u/columns) for example etc.
My feeling is that keeping application state strictly in global state would
make some things easier (testing+debugging UI components, recording user
sessions in full detail by listening on :tx-listen etc.). But blindly
following all-in-global state also can have its pitfalls that I'm not aware
of (as cljs/reactjs/om newbie).
There are the following aspects of UI state as I see it:
- hardcoded UI config data (widget descriptions, column descriptions etc.);
- customizable UI config data (eg. skins and styles that application user
can choose);
- UI code (function references sometimes bound somewhere to application
state);
- UI state (eg. currently edited data, flags marking that data is being
edited/viewed row being selected etc.)
- business data (fetched REST from backend);
- inherently stateful stuff (eg. core.async channels);
- etc.
My question is: where would you recommend placing individual bits of
config/data/state listed above (global state? local state? :opts ? global
:shared ? etc.) ?
Regards,
rle
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
