If you store it in app-state, you can use ref cursors to access it. This
way you can separate global from local by storing it under a separate key
or something similar.

If the parent of your toggle component knows about the toggle component,
then it can merge this additional state (which it may store in component
local state or in app-state and access through ref cursor) into the cursor:

(om/build toggle-component (assoc data :selected-field selected-field))

However, I don't know of any way to make this work so that the
toggle-component can transact on this additional cursor field. The
toggle-component would have to send a message back to the parent to tell it
to modify the field, perhaps by passing in a callback:

(om/build toggle-component (assoc data :selected-field selected-field)
{:state {:set-field #(om/set-state! owner :selected-field %)}})

Or use some sort of (perhaps core.async based) messaging.

If the parent does not see the state and you don't want to store it in
app-state then the only remaining place for it is the toggle components
local state.

I personally prefer to keep all state in the global atom, even if it's
local. I place the different types of state at different keys in the global
atom to maintain some separation between data from the domain model, the
view data, temporary scratchpad data etc.
This is also one of the reasons that I ultimately switched to using
re-frame (and therefore reagent): I didn't want to use Om's local state, I
wanted a uni-directional data flow and I wanted to move all update logic
out of the components into a single place (re-frame handlers). Made my code
much simpler.
So personally, I would aim for a similar style in om if possible.

How that helps.

On Wed, 15 Jul 2015 06:20 Asher Coren <asherco...@gmail.com> wrote:

> On Tuesday, July 14, 2015 at 6:59:14 PM UTC+3, Tyler Morten wrote:
> > On Tuesday, July 14, 2015 at 4:51:15 AM UTC-5, Asher Coren wrote:
> > > Hello,
> > > Sometimes, when building components, they depend on internal logic
> that the entire app doesn't care about. For example: A toggle button that
> toggles display between two fields from the app-state. The status of the
> toggle (which of the fields is displayed) is only the concern of the toggle
> component.
> > > I know it is possible to store this local state in the local state of
> the component, but is there a way to add it to the cursor of the component
> without changing the app-state?
> >
> > I'm not an expert in Om, but I think this (toggle field state) is the
> perfect example of what to store in the local components state and not in
> your application state.  I suppose if you REALLY wanted to you could store
> this in your app-state and just mutate a :selected-field...i.e.
> >
> > (defonce app-state (atom {:selected-field :first-field))
> >
> > (om/update! cursor :selected-field :first-field)
> > or
> > (om/update! cursor :selected-field :second-field)
> >
> > In the render function, you can select what field is visible via display
> helper function:
> > (dom/input #js {:style (display cursor :first-field} "Field #1")
> > (dom/input #js {:style (display cursor :second-field} "Field #2")
> >
> > (defn display [cursor field]
> >   (if (= (:selected-field cursor) field)
> >     #js {}
> >     #js {display: "none"}))
> >
> > I think this would work...is this what you were thinking?
> > Tyler
>
> Your idea for storing it permanently in the app state will work, but it
> doesn't look natural to have such a local field in the app state. I'm
> looking for a way to inject it in to the app state only when viewing that
> component.
>
> A note about your implementation: Your `display` function is not
> necessary. There's no need to add a `display` property to the field; Simply
> build the required component according to the state:
> (dom/input nil selected-field)
>
> --
> 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.
>

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

Reply via email to