Yes, React really doesn't want you to mess with its DOM nodes (and if you do, you have to make sure that they are not re-rendered by React, otherwise horrible things will happen).
The cleanest way to handle drag-and-drop is probably to change your "model" (i.e some state in an atom) when the drop event is triggered, so that some content is rendered in a new place rather than in the old. I don't have any direct experience from goog.fx.DragDrop, though, so I can't say for sure how easy it is to adapt to a non-DOM-centric model like React's. /dan On Tuesday, February 18, 2014 4:29:51 PM UTC+1, ritchie turner wrote: > Hi Dan > > How would you recommend dealing with drag/drop in reagent? > > I probably want to use the goog.fx.DragDrop functionality and move nodes > between parents (components) > > However, reparenting like this seems like a great way to confuse react > > (defn- ondrop [event] > (let [ti (.-element (.-dropTargetItem event)) > si (.-element (.-dragSourceItem event))] > (set! (.-background (.-style ti)) "silver") > (dom/append ti (dom/removeNode si)))) > > > rather I should be update the atom appropriately and redraw the component > with a new node or not, which means the component needs to know that there > are items to be rendered that won't be there to start with and so on. Seems a > bit more complicated. > > > Thanks > > Ritchie -- 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.
