Thanks! Also - updating to om 0.2+ will improve the readability of this, as it'll remove references to "opts" and will also allow the new "shared" global state (which will eliminate some boilerplate reference-passing).
Another thing I think I need to do is to make "bounds" reporting hierarchical, so only the encapsulating component hears about bounds for it's sub-components. That would allow the actual sortable stuff to work out better (since I'd use the bounds of the draggable objects to calculate the current "next item", in case we have a heterogeneous list of drag-objects we're re-ordering in our sortable). On Tuesday, January 21, 2014 11:25:39 AM UTC-8, David Nolen wrote: > This is great stuff! :) > > > > On Tue, Jan 21, 2014 at 2:22 PM, David Pidcock <[email protected]> wrote: > > > > Sure. I have a version @ > > > > https://gist.github.com/anonymous/8546161 > > > > Note - this is om 0.1.7 compatible. I have yet to update it to 0.2+ > > > > Also, I am still learning myself, so I'm not certain I'd call it "idiomatic" > of anything, yet. > > > > Many thanks to David Nolen for his example sortable (many of the functions > are lifted as-is from there). > > > > The main difference in this approach is that it's intended to be a "bolt on" > feature. The containing component (the "main app", if you will) just calls a > couple of functions during initial setup and update etc and it's all > externalized. > > > > > Subcomponents then "subscribe" for drag events within their bounds with > another function, and this allows us to drag and drop between different > components with the same event channels. > > > > Drop handlers use a "command channel" to send a higher level command back to > the main component, which mutates the app-state according to whatever > business logic you'd like. > > > > Theoretically, the drop handlers could mutate the state at the subcomponent > level, but I prefer to centralize this at the main-app, in case some kind of > inter-component coordination is required. It also means all the drag > functions can be re-used very easily. > > > > > There are no doubt many ways this could be improved, and I'm exploring > several options, including injecting pre-filtering logic at the main app > level so that I can support drag-exit and drag-enter style events. > > > > > > > > > > On Monday, January 20, 2014 10:16:02 PM UTC-8, vladislav p wrote: > > > @David P, > > > Would you be able to share your code samples on githubs or ghist > > > I am slowly venturingin in to this stack and would appreciate to see D&D > > and other examples showing idiomatic use with Om. > > > > > > thank you in advance > > > > > > > > > On Monday, January 13, 2014 6:23:44 PM UTC-5, David Pidcock wrote: > > > > Perfect. > > > > > > > > That worked wonders. I just had to thread the owner into the filter-fn, > > > instead of the bounds by themselves. Still learning to think > > > declaratively, obviously. > > > > > > > > No more channel churn. > > > > -- > > 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.
