Minor typo correction: " I know if my components use *-nr! functions because all of my state access is local to the function"
That was meant to say "local to the component". On Mon, 15 Dec 2014 08:54 Daniel Kersten <dkers...@gmail.com> wrote: > 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 <andrew...@gmail.com> 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 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.
