There is some explanation about component local state in the documentation here:
https://github.com/swannodette/om/wiki/Conceptual-overview UI components will often have transient state that really doesn't make sense to expose externally. For example the characters in an input as someone is typing, or the highlighted? bool for some mouse-over logic, that kind of thing. Also, component local state is always up to date, whereas the global state is updated in a more stepwise fashion with each call of the render loop. -Jeff On Thursday, March 27, 2014 4:20:41 PM UTC+8, rlewczuk wrote: > > 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.
