I always communicate values to children to keep them decoupled from their parents. I don't think there's any technical reasons to avoided your approach, but I don't like components relying directly on the structure of other components.
I also try to represent the bulk of my state in the cursor and try to keep a nice pure data-in-dom-out thing going, but this is often not possible without polluting app state with components' transient state. But this does mean that I don't need to pass a lot of state to children and can do so using :init-state and :state. For writable data I use callbacks or core.async channels. As for calling get-state from a handler, this should always work as long as you're careful that the handier cannot outlive the owner. I usually don't call get-state in a handler/callback but instead use render-state with destructuring and then have the event handlers close over the values. This works as long as the state is never set with the *-nr! functions as any time the state changes, the component rerenders and updates my handlers. If this isn't the case (eg because you do use *-nr! functions [1]) and you need up to date state, then I see nothing wrong with calling get-state. [1] This is another reason I personally prefer not to pass the parents owner: I know if my components use *-nr! functions because all of my state access is local to the function. If I pass the owner to other components then I need to be aware of how they access my components state too. If your app is large and/or you work in a team, this only gets harder. At the end of the day, though, use whichever approach works best for you. Re: waste, because of the immutable data structures and structural sharing there should be less wastage than it looks. Re: reading cursors in handlers - this shouldn't be a problem as long as you deref them. The only thing to be aware of is that by default only maps and vectors get turned into cursors, so if you eg access a map field and it contains a vector and your handler closes over that, then you must deref it (and you will get up to date data), but if the map field instead contains a value like an integer or string, then it's not a cursor and you don't deref it (and the value might be stale by the time the handler is called). Once I internalised this, I stopped getting cursor errors. On Mon, 15 Dec 2014 08:29 Andrew <[email protected]> wrote: > I've been using get-state in my event handlers without problem, but I'm > wondering if I should be concerned by not treating these in the same way I > treat app-state cursors, which generally should not be read in an event > handler, correct? That is, while update! and transact! are usually fine in > an event handler since the data is not read, get-state obviously does read > data, so is it a similar concern? > > I often pass a parent component down through children so they can read > certain aspects of the parent's state, hence why using get-state directly. > While I pretty much always get Om errors when I try to read an app-state > cursor in a handler, I never get them when reading local state. So I wonder > now if I'm getting a false sense of security with this habit if it is not > advised. > > I suppose an alternative would be to pass actual parent state values down > so they are mirrored among children, rather than passing the parent owner > itself. This would allow an event handler access to values without calling > get-state on another component. But it seems wasteful to do so. > > -- > 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.
