Hi Rle,
I'm a clojurescript / om newbie too. I'll try to answer to the best of my
knowledge and maybe someone else can improve this first guess.
Il giorno giovedì 27 marzo 2014 09:20:41 UTC+1, rlewczuk ha scritto:
>
> 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.
>
Don't mess up application state with view state information. You can keep
your current / editing row in the local state of a table component that
contains your row components. As a further optimization you may render your
table as pure html and mount a row component over one row only when editing
it. Om components are already flyweight. If it's feasible and how easily it
can be done seems to be a matter of react.js (owner of mount / unmount
lifecycle) more than om.
As a rule of thumb for myself: application state should not change if you
change your view (e.g. represent data with a table or with a chart). It may
be bound to your use case. So if it contains some flags for user
interaction they are ok.
>
> 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).
>
When you add a component you need to make rooms for its state in the
application state. I fear this is very error prone.
>
>
> There are the following aspects of UI state as I see it:
>
> - hardcoded UI config data (widget descriptions, column descriptions etc.);
>
pass them in as :opts
>
> - customizable UI config data (eg. skins and styles that application user
> can choose);
>
in the application state; you can load / store them in a user profile at
the server side
>
> - UI code (function references sometimes bound somewhere to application
> state);
>
(not sure I understand the question) may be in functions in the same file
of your component definition functions
>
> - UI state (eg. currently edited data, flags marking that data is being
> edited/viewed row being selected etc.)
>
in local state
>
> - business data (fetched REST from backend);
>
in application state
>
> - inherently stateful stuff (eg. core.async channels);
>
in local state or in global shared state for inter components communication
>
> - 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
>
>
> I hope this helps,
Luca
--
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.
