Apparently David is relaxing the restriction of not being able to access
cursor outside of the render phase without dereferncing, although it's my
understanding that deref is still necessary if you require an up to date
view of the cursor, so it's probably still variable to make the distinction
between render phase and not.
The render phase is basically any code within the lifecycle functions or
functions called directly by the lifestyle functions.
On the other hand all event handlers (:onClick, setTimeout and anything
else where a function is called for you at a later time) are not part of
the render phase. That is, event handlers attached to dom nodes are never
part of the render phase (but callbacks passed into your component and
called by you inside a lifecycle function is).
As for state destructuring, its not uncommon that I have code like this
(although I do try to minimize local state use when possible just to
maintain functional purity as much as I can):
(defn child [data ...
(render-state [_ {:keys [foo bar]}]
(dom/div
{:onClick #(something (+ (:val @data) too)))}
bar)))
(defn parent ...
(render-state [_ {:keys [quux]}]
(om/build child data {:init-state {:bar "ABC"}
:state {:foo quux}})))
Apologies for bad formatting and typos, not easy typing code on a phone :)
On Mon, 15 Dec 2014 09:03 Andrew <[email protected]> wrote:
> 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.
>
--
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.
