Rework (v3)

[JakeSidSmith]

Before alpha release (3.0.0-alpha.0)

• [x] Adjust how components are passed in (as children)
• [x] Update readme
• [x] Support for ImmutableJS (call toArray on Immutable Lists)
• [x] Callback only supplies previous & next indices
• [ ] Callback supplies additional boolean as to whether the item was dropped on another item (or between them)
• [x] Add helper methods for reordering
• [x] Auto-scroll while dragging
• [x] Allow defining the tag to use for the wrapper
• [x] Use JSX in examples
• [x] Fix React 15: "This synthetic event is reused for performance reasons" on mobile
• [x] Continuous integration (CircleCI)
• [x] Optional autoScroll
• [x] Optional autoScrollParents
• [ ] Optional autoScrollWindow
• [ ] Disable reordering certain components with data-reorder-disabled prop
• [ ] Allow programatic disabling of drag and drop for a list (#70)
• [ ] onReorderStart callback (#85)
• [ ] Abstraction for merging custom props with injected reorder props (when supplying a SFC or class)
• [ ] Do not begin reordering if reorder is in progress (allows nesting reorder components)
• [x] Additional examples
• [x] Tests (Mocha)
• [ ] 100% coverage
• [x] Setup CI
• [ ] Update readme again
• [ ] Mention draggable={false} to prevent image dragging
• [x] Placeholder class correctly applied. Fixes #76
• [ ] Test in React 0.13, 0.14 and 15

Next

• [x] Support dragging between lists
• [x] Callback supplies list IDs where necessary

Soon (Possibly)

• [ ] Support multi-select / drag

[HriBB]

@JakeSidSmith is there anything we can do to help you out? Maybe create some examples? I'm using version 2.1.0 and it works great on desktop, but has problems on mobile, so I'm looking forward to this PR.

[JakeSidSmith]

@HriBB I've been pretty busy, but feel free to fork from this branch & contribute. When you're happy, open a PR against this branch. :)

Was going to sort out the auto-scrolling next, but have to make sure this is accounted for. You can have a go at that if you like?

One thing to bare in mind, I'm changing the auto-scroll area bounds a little. They should be 33.33% of the width / height... but no larger than 20px or so (have not decided on an exact value yet). This way there's a 33.33% dead zone in the center, but shouldn't take up so much room on large containers.

Got a start & watch script for the examples (where I've been testing stuff).

npm start
npm run watch

[oyeanuj]

Hey @JakeSidSmith! I am wondering if in your upcoming rework, there is going to be support for optionally overriding the sorting behavior?

In my use case, if a user drops an item in between others, it sorts the list but if the item is dropped on top of another, I can perform a different operation. So, to do this, I would need to know if an item is dropped on top of another (and not calculate new position in this case), or above or below the other (calculate new position in this case).

Would that be possible?

[JakeSidSmith]

This may be possible already, @oyeanuj. Unsure if it'd work with existing releases though... in theory you could add a touchend and mouseup listener to your items. When this is triggered you store the event.target, then when the reorder callback is called you can tell if if was released on one of your items. You also need to clear this on touchstart and mousedown on the window though, to prevent it thinking you have dropped it on the same item, because this was the previous drop location.

I'll bare this in mind. Perhaps I can add an argument to the callback that lets you know if it was dropped on an item, or in between. :)

[oyeanuj]

Thanks for the tip!

And yes, that argument to the callback would be great as well - especially since otherwise, I'll end up replicating logic thats in the library, outside the library as well.

Btw, just curious, how close are we to v2? :)

[JakeSidSmith]

If I rolled back the last few commits, it'd be good to go, but with no support for multi-list reordering, which is the main reason for the rework... so although it has nicer syntax now, support for ImmutableJS, and a lot more features, it wouldn't really be worth releasing.

I may release an alpha of the rework that's stable. Would be good to get some people testing it, and allow them to setup for the release of the multi-list stuff.

[JakeSidSmith]

@oyeanuj I didn't really answer your question though. XD

Basically, the multi-list stuff is the next hard thing to do, then a few little features & get coverage up to 100%... then I can release the full version.

I'd say it'd only take a few days of solid work, but I'm unsure when I'll have the time for it soon.

I'd love to get it done soon, as I need some of these features for another project of mine, so will be trying to put some time in whenever I can. :)

[oyeanuj]

@JakeSidSmith got it, thank you for the update!

[JakeSidSmith]

@oyeanuj update: you wont be able to check if you're hovering over an element with touchend or mouseup on the element itself I don't think, as the dragging element will be in the way. Instead you'd have to add a listener to the window, or use the reorder callback & check the mouse coordinates against the items in your list to see if it's over any of them.

[oyeanuj]

@JakeSidSmith Interesting. One other idea - What do you think about a prop that allows you to configure the droppable area of an item? And then the reorder callback just specifies whether it was in the droppable area or not, or if it was in the middle of two list elements?

[JakeSidSmith]

@oyeanuj it'd be much easier to just say in the callback if the item was dropped on another, than if it was on a specific element inside an item. Not entirely sure how you'd configure that. With data attributes?

[JakeSidSmith]

Could you open an issue to discuss this, and post your ideas there. Some code examples of a droppable area would be good. :)

[JakeSidSmith]

Update: just released 3.0.0-alpha.0 on npm. I'd suggest checking out this version, it should be far more stable than the existing release, fixes a lot of bugs, and adds the ability to drag between lists. :)

See the readme after installation, there's been a considerable change to the interface.

[tmm1]

Would love to see this PR merged and 3.0 to become an official non-alpha release.

[JakeSidSmith]

@tmm1 as would I. There's just a few issues / improvement to add (tracked here). Hard to find the time to address these, but v3 is in a much better state than v2, so I'd recommend moving to the alpha anyway. 🙂

[tmm1]

I have already switched, and agree that the api is much better and that v3 works much better. Thus I would recommend merging this PR and releasing 3.0.0, and then addressing the remaining items in follow up releases.

[tmm1]

Alternatively do a beta release, because "alpha" does not do justice to how well v3 works :)