I personally like keeping the incidental local state local to components
and keep the app state purely for domain data. Therefore I would use the
local state like you said and use the cursor only to point at the tag list
being modified.
As for how to manage the local state with sub components, you basically
have two options (not including core.async):
1. You can use :init-state and :state in the om/build options to pass state
to the child component
2. You can add additional data to the child components cursor, eg:
(om/build tag-component {:extra-data foo :tag (:tag cursor)})
Since the child component is private, you could put whatever local state
you want into the cursor without exposing it to the user of your component.
Note that you won't be able to call update or transact on this additional
data, so you won't be able to directly modify the parents state. You could
use a callback or core.async to communicate with the parent.
I use the first option where possible and the second if the state is part
of the domain data from the child's perspective (but in reality is
generated by the parent) - usually when the child isn't private.
On 10 Oct 2014 00:05, "Stephen Wakely" <[email protected]> wrote:
> I've just finished writing my first Om component (
> https://gist.github.com/FungusHumungus/aa6527505c24f7e2c83f). I have a
> sneaky suspicion that I have gone the wrong way about it, and would like to
> know what a more idiomatic way to develop this component would be.
>
> The component is a simple Tag selector. The user can enter multiple tags
> and choose them from an auto complete list - similar to the tag entry field
> on stack overflow.
>
> Because this is a component, I don't want it to pollute the global
> application state. It should only mutate one field - the tag list. There is
> a lot of other state that this component needs to maintain - the choices in
> the autocomplete list, the currently selected item, the currently entered
> text.
>
> I am not sure what the best way to maintain this other state should be.
> The way I have approached it is to use the component state. The problem
> with this is that I am then prevented from creating other sub components
> easily. It seems the component structure needs to map onto the global app
> state via cursors in order to handle the needs updating event.
>
> So rather than creating separate components, I have one big component and
> am just creating standard Clojure functions that create the various dom
> components as necessary. The owner and cursor of this component gets passed
> around an awful lot. This doesn't feel tidy.
>
> I'm pretty sure one disadvantage of having one big component rather than
> multiple nested controls is that for every change in the state, the whole
> control would need to be rebuilt. I realise React does help a lot here by
> maintaining its own copy of the Dom, so really minimal aspects of the Dom
> are changed - but I am still looking to find the best solution from the
> start.
>
> I have been thinking using core.async channels to share state between the
> controls might be an alternative, but I'm not convinced it would be more
> efficient.
>
> Is there a better way?
>
> Thanks
>
>
>
> --
> 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 [email protected].
> To post to this group, send email to [email protected].
> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/clojurescript.
