2.0 roadmap

[PuruVJ]

Docs are coming along quite well, and its time to address the upcoming changes in Neodrag 2.0

All the different libraries will be upgraded to v2.0, even those not on 1.0 yet. This is to make things consistent.

This version, Im introducing a new @neodrag/core library. This will be a package in the monorepo, won't be published to npm. All the functionality from @neodrag/svelte is extracted to this now.

So, getting on, changes to the core library:

Switch to pointer events.

Status: PLANNED

RIght now, I am assigning 6 event listeners to window for each draggable instance:

• mousedown
• mousemove
• mouseup
• touchstart
• touchmove
• touchend

Using pointer events will cut these in half and make it only:

• pointerdown
• pointermove
• pointerup

Reducing event listeners to just half, as well as reducing bundle size by remove 3 event additions and deletion, so 6 lines. Will also remove the isTouchEvent functions, as they'll not be needed.

This will allow me to remove ignoreMultitouch entirely

Use WeakMap to store draggable instances

Status: RESEARCHING

Use WeakMap to store draggable elements. Instead of attaching 3 event listeners to window for each draggable, this approach will allow to set only 3 event listeners for the entire page, no matter how many draggable instances you have. Every time u call draggable on an element, it will add the node and options to aWeakMap, and the 3 global event listeners will figure out the element to work with

I have frankly no idea how to make this work yet, my above descriptions could be utterly wrong as to the final product. Neither do I know if it will be performant at all. Theoretically, it should be, but practically, I'll have to test. I am not familiar with how to benchmark these DOM things in browser, so any volunteer help is appreciated.

Serve output formats unminified

Status: PLANNED

Currently, even in npm builds, I am serving terser minified source code, along with sourcemaps. But sourcemaps are finicky, and I have decided to ditch sourcemaps completely, and will now provide unminified output, for better debugging by the user. Will make sure to serve index.min.js version too, for unpkg, or in case you want to manually include them in npm.

Frankly, this will make the final bundle size of user's output a little bigger. For example, if they're using esbuild for bundling and minification, the library code minified alone could be up to 30% larger. They can always include the index.min.js files manually, but this would be a breaking change of sorts, if users want to keep the previous bundle sizes

Allow delay option

Status: PLANNED

Right now, you click on a draggable and start dragging it, it just start working. However, sometimes you want a little delay of 50-100ms before you can start dragging it. Maybe to put styles on it to show that the element can be dragged now.

So that's why, I intend to add a delay option.

My intended API design:

<!-- 50ms -->
<div use:draggable={{ delay: 50 }}> Drag me </div>

Internally, it will be equal to putting an await sleep(50) in the pointerdown event, on the first line itself. So this will affect only the starting of drag. Won't add a delay to the actual dragging of the box over the pixels.

Option naming can be bike-shedded, opinions welcome in comments.

Move to translate property

Status: PLANNED

Currently, the dragging is applied using transform: translate3d(20px, -30px, 0)(Or transform: translate(20px, -30px) if you have gpuAcceleration set to false). This has a big issue of not being able to apply other transform properties as this would override the existing dragging translate.

So will now be switching to translate property entirely. This will be a breaking change for older browsers.

However, because the browser support globally is only 88%, I will be allowing a new option legacyTransform, which will switch back to transform rather than translate property. This will be applicable only till the next major version, or the next to next major version. Depending on when browser support goes past 95% support. Track here https://caniuse.com/?search=translate

Issue brought up in #72

Allow specifying when bounds are recomputed

Status: PLANNED

Currently, the bounds are computed on pointerdown, aka when u start dragging. But you might have a use case where you want them recomputed while dragging too. That is off course gonna be a performance bottleneck, hence it won't be the default mode. Instead, it will be left to the user whether they are fine with incurring this additional cost or not.

Instead, I will expose a new option:

{
  recomputeBounds: {
    dragStart: true,
    drag: false,
    dragEnd: false
  }
}

This will allow you to configure when you want ur bounds recomputed. The above values will be the default value of recomputeBounds option.

Brought up in #64

Expose the node element, and draggedElement in events

Status: PLANNED

Right now, events expose 3 things:

{
  offsetX, // How much the draggable moved since initial position, x axis
  offsetY, // How much the draggable moved since initial position, y axis
  domRect // Literally node.getBoundingClientRect()
}

I intend to expose 2 new things here:

rootNode: The node on which draggable is applied
targetNode: The element which was actually dragged. This could be the same as rootNode or one of the handles.

And I propose removing domRect, as you can call rootNode.getBoundingClientRect() yourself.

Final value returned:

{
  offsetX, // How much the draggable moved since initial position, x axis
  offsetY, // How much the draggable moved since initial position, y axis
  rootNode, // Node on draggable is applied
  targetNode // Node which is dragged. Could be the handle or the rootNode itself, depending on the options passed
}

I acknowledge that having a domRect property just ready for you to use is easier, however it can upset the performance by a bit, and makes the code a little harder for the maintainer.

That's why, I'm up for discussion about this. Feel free to let me know why you think this property should stay.

Brought up in: #58

Properly throttle to requestAnimationFrame

Status: RESEARCHING

Recently came across this blog post. Gonna see if it helps https://nolanlawson.com/2019/08/11/high-performance-input-handling-on-the-web

Conclusion

These are all the changes I consider doing in 2.0. There are a bunch of post-2.0 changes that you can see in this milestone: https://github.com/PuruVJ/neodrag/issues?q=is:open+is:issue+milestone:post-2.0

If there's any feature in here that you consider absolutely important for 2.0, let me know

[santiagopuentep]

The roadmap sounds great!

As discussed in #76 I think that the option to add a delay should be replaced by an option to be able to imperatively start de dragging, because otherwise implementing some other custom drag start would be impossible. For example, we need to be able to start the drag only after the pointer moved a certain amount in the x or y direction (a dead zone). With the delay only that specific problem is fixed, but not all cases.

Maybe change the controlled component to be truly controlled?