Fork me on GitHub

Hey Tony and all. First off, Fulcro is really wonderful, and the documentation is really exemplary across the board; thank you so much. I'm working on a hand-rolled drag-and-drop implementation, and I'm having issues right now. Without diving into those, I wanted to sanity-check my approach, and follow-up with bugs after I do that. Here's what I have so far:


My design expects only one component to be dragged at a time, and therefore, any state coupled to dragging should be at the root of the tree; it's not component specific. Hence:

(defonce app (atom nil))
(defcard-fulcro card-list-live
  {:inspect-data true
   :fulcro       {:started-callback #(reset! app %)}})
That way I can use #(prim/transact! (:reconciler @app) ... to make changes to the root from any component mutation.


For the component part of the dragging effect, fundamentally I just need an onMouseDown event handler to note its initial location and flag it as a drag if the mouse moves a particular distance; then to update the style with position: absolute; top: ...; right: ....


Rather than rolling this out for each draggable component (which frankly wouldn't be that much code, but is clearly not the most elegant approach) it seemed most fitting to create a HOC (higher order component) that wraps a div around a draggable component:

(defmutation on-pointer-down
  "To be used on any mousedown/touch event on a draggable object."
  [{:keys [event]}]
  (action [{:keys [state]}]
    (swap! state assoc :draggable/pointer-down-position (u/client-x&y event))))

(def draggable-next-id (atom 0))
(defsc Draggable [this {:keys [db/id]}]
  {:query         [:db/id]
   :initial-state (fn [] {:db/id (swap! inc draggable-next-id)})
   :ident         [:draggable/by-id :db/id]}
  (let [children (prim/children this)
        opd      #(prim/transact! (:reconciler @app)
                    `[(on-pointer-down {:event ~%})])]
    (dom/div :.draggable {:onMouseDown  opd
                          :onTouchStart opd}
The unique ids here are so that the specific instance being dragged can have its wrapping div's position changed via updates to the inline style (I haven't yet created the mutation for that).


Finally, it looks like this when used (this is the Render body for one of my draggable components): (ui-draggable {} (dom/div :.card text)) Now, I'm getting runtime errors with this design, but before I get into that tomorrow: does anything jump out to anyone here as problematic, whether it be a technical issue or questionable design?


That was a lot; thank you in advance for your time and any feedback.


@montanonic is there a reason you can't use some external library to deal with the drag-drop? I'm asking because D&D is not a simple feature to implement (specially if you want to it to perform well), unless you really understand what you are doing, I recommend dont, instead you can delegate that to some good implementation like react-dnd


@montanonic Assuming you don't want to use a library or HTML5 drag-n-drop support: The HOC pattern is described in the book. There is an extra step because of some internal dynamic vars. It's ok to transact against the reconciler, and that will cause a root render. Root renders will re-run the query.


If you need that data in a bunch of components then you might also look into :shared and :shared-fn (which only update on root refresh, BTW)


If you're seeing errors, I'm betting the HOC is your problem, which is correctable as described in the book


Those bindings are what I was referring to, and they are needed if you "do something" with the element that isn't part of Fulcro transition libraries do...they might clone/re-render the low-level element outside of mainline rendering.


recently I've started using Specter which boasts that it's much faster than update-in and get-in. I wonder if Fulcro could get a performance boost from that.


@roklenarcic The problem is the performance gains are due to path compilation, and Fulcro’s paths are all dynamic…so I think it ends up being slower for the things that matter


I think…not sure. I’m not an expert on specter


As far as I understand, the new version (0.11+) has achieved that performace without compilation.


Or with less of a difference


I just suggested a second look, as it seems that things have changed for that library.


In any case I don't have performance problems as such so it's not a big deal.


Wiliker, thanks for your feedback. This is a hobby project where 1/2 of my interest is in building my app, but the other 1/2 is in building proficiency with Clojure, Fulcro, and my own library-making abilities, which I greatly enjoy doing. DnD is an interesting problem to me and it's fun to work on implementing it. Tony, thank you very much for the help; I'll focus on those sections of the book and see if I can fix my code.


@montanonic sure, it can be a lot of fun if you have the time, so if I wanna go that direction I have a few tips: when doing things in animation fashion (like dragging something around), to get it to perform well you must take control over that node directly, that means don't use react lifecycle to update it, thats slow, instead of you get a hold of the node and manipulate yourself, once you are to finish the drag process (or maybe using a debounce) you sync back with the react state, this flow can give production grade speed

👍 4

That's helpful. I was considering using fulcro events to add the mouse position as a key on the root, which the dragged component would use to set its position via the style attribute. So you'd suggest instead to move that state and calculation outside of fulcro/react state and updates, and then resync after? I'm just trying to make sure I understand what you mean by using the lifecycle, and to see if my original plan above would be doing that, and therefore be slow.


yes, you got right, move that state and calculation outside fulcro/react and resync later

👍 4

Great. Thanks a lot for the info wilker.


That's helpful. I was considering using fulcro events to add the mouse position as a key on the root, which the dragged component would use to set its position via the style attribute. So you'd suggest instead to move that state and calculation outside of fulcro/react state and updates, and then resync after? I'm just trying to make sure I understand what you mean by using the lifecycle, and to see if my original plan above would be doing that, and therefore be slow.


I updated my fulcro dependency from 2.5.9 to 2.6.0-rc3. I'm getting this error on the server

Mon Jul 16 14:57:32 PDT 2018 [worker-2] ERROR - GET /js/cards/cljsjs/showdown/development/
java.lang.IllegalArgumentException: Cannot open <nil> as an InputStream.


The behavior seems to be that I get ERROR - GET / when I refresh the page on localhost:3000, the dev part, and ERROR - GET /js/cards/cljsjs/showdown/development/ when refreshing on localhost:3000/cards.html. I have two repls, one with Figwheel Cards + Dev, and other with the server that's giving these errors. It seems like the only issue is that I won't be getting some source maps; everything that I care about looks fine. Nonetheless, I don't like getting errors, so wanted to ask what might be up.


@montanonic That sounds like more of a potential shadow-cljs/package.json kind of issue. RC3 changes nothing about that


Hmm, not using shadowcljs


ah, ok… 🙂


showdown ~ shadow XD


thats a dep required by Devcards


could be that the two cljsjs things you’re using don’t have source maps in them


Just using [cljsjs/react "16.4.0-0] [cljsjs/react-dom "16.4.0-0"]


No worries about this doesn't seem to affect me in any negative way. But I wasn't getting this before updating fulcro from 2.5.9


I did not update anything else or change code


could be the upgrade to fulcro also got you an update to figwheel/devcards?


in any case: it’s just missing source maps, which aren’t part of Fulcro for those anyhow

👍 4

Cool. Thanks for the help. I'll maybe look into this later and see if I can figure out what changed.


I've made a bit of conceptual progress on my earlier Drag-and-drop oriented questions. First off: stupid typo, I was using (-.clientX event) instead of (.-clientX event) in my code. Now events fired by my Fulcro "wrapping component" work (because the underlying code isn't broken, hah). Second: I've still had to continue wrapping my head around how initial state works. I'm used to initializing certain props in React inside of its constructor, and assumed :initial-state (fn [_] ...) would run when passing props to (ui-some-component some-props ...), but actually the initial-state function will only run when get-initial-state is used. So if I have a wrapper like ui-draggable, and a component that uses it like (ui-draggable {} (dom/div "I'm another component)), no props will be initialized in ui-draggable, even if its :initial-state has default values initialized.


that's correct, initial-state is not about component state, it's about database state (fulcro db state)


Now the next thing for me to tackle is initializing component state without having to query it, so I'm thinking I could actually use componentDidMount for this?


Or would that just be a bad path to go down?


bad path, you should initialize it previosly


on app start, or when you create a new data entry for that on the db


What if my component state is just generating a unique id, that's it?


still should go though initial state


remember the view is a reflection of your db state


I want to wrap some ui elements in draggable without them having to change their query or initial state code, that's the reason I'm trying to figure this out


so the DB must be initialized before your components


But also what I'm trying to achieve might be simply wrong to do in Fulcro, which is fine.


Okay, I think I actually have an idea here. Thanks for your feedback, that helps me to understand what's going on.