Thanks Daniel. Two followups: You say that render-state destructuring is preferable to using get-state, but of course render-state is only going to show you that component's own state, and thus using get-state would be necessary if accessing another component's state. I understand your point about passing values directly rather than a "pointer" to the parent "object", so I'll give that some thought.
You said: "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." This line of thinking is something I hear often, knowing where your event handlers live in the context of the greater app and its rendering. I am not a JS guy with lots of browser experience, so I don't know how to answer questions like these. How do I be careful a handler is not outliving its owner? Related to this, how do I know if a handler is inside or outside the render phase? On IRC it was suggested that it is up to me to figure that out, but that seems like a low-level issue that would never be obvious in the context of standard Om programming. For example, deref is not necessary in an event handler if it is in the render phase, okay, so how would I ever know if :onClick or :onChange are occurring during render or not? -- 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.
