Events use the flyweight pattern and are effectively nil after the
callback. Dispatch is async so you need to extract what you need from the
event in the callback and pass that into the dispatch.
On 22 Jul 2015 21:10, "David Pidcock" <eraz0rh...@gmail.com> wrote:

> I'm playing with Reagent + re-frame  (and re-com) for a toy project of
> mine and I noticed something strange.
>
> I'm creating a component I want to use to drag things around with:
>
> (defn drag-handle
>   []
>   (fn []
>       [re-com/label :style {:padding "5px"} :label "||"
>        :attr {:id (:id combatant)
>               :draggable true
>               :on-drag-start #(re-frame/dispatch  [:drag-start  %])
>               :on-drag (fn [event]
>                          (prn (.clientX event))
>                          (re-frame/dispatch [:drag  event]))
>               }]))
>
>
> The handler looks like this :
> (re-frame/register-handler
>   :drag
>   (fn [db [_ event]]
>     (prn "after dispatch ; " (.-clientX event))
>
> When I use dispatch asynchronously   (.-clientX event)  is correct when
> printed from the function attached to the component, but nil when it
> reaches the handler.
>
> if I use dispatch-sync, the output is consistent.
>
> Is this a bug in re-frame/dispatch router-loop code , or core/async?  Or
> expected behaviour?
>
> I haven't tried this with a vanilla (chan), and I've only tested in Chrome
>
> Could it be that the javascript object isn't "realized" until it has been
> read, and the mouse event is "dead" after the router-loop executes the  (<!
> (timeout 0)) ? -- I have no idea :D
>
> Another weird thing : on-drag doesn't fire the first time I drag the
> handle.
>  on-drag-start does fire, but then I have to "let go" and (without
> selecting a different object) start dragging again to get the on-drag
> events flowing.  (This might be an artifact of html5's drag implementation
> -- I may need to go back to mouse-down/up/move)
>
> This also raises the question of whether I should be dispatching the drag
> events  through re-frame's router.
>
> So for those of you with more experience building with these tools, I ask
> : might it be better to have a special channel to handle drag events (still
> in app-db, accessible via re-frame/subscribe) which would not need to
> compete with potentially long-running event handlers?
>
>
>
> --
> 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.

Reply via email to