Allow instances to handle more than one element

[swang]

Hi. Just seeing if you're interesting in adding this before I implement it.

I want to have one instance of Draggable handle all elements that match an element. Easiest example is I have a chessboard and want to be able to drag all the pieces on the board without having to declare 32 instances of Draggable. E.g. I want to specify that I want all (<div class="piece"></div>) that are children of a parent element (<div class="board"></div>) be draggable.

The way I'm thinking of implementing this is to specify a new parentEle parameter, and make element accept a string. Then only need an event listener attached to parentEle instead of for each element. I'm not dead-set on names/functionality so if you are interested, would love to hear your feedback about how the API should work for this.

I know this library wants to support IE8, and it seems that querySelectorAll actually works in IE8, but only if its in standards mode[0]. I don't think polyfilling querySelectorAll would be worth it just to support IE8 quirks/compat modes. So implementing this for IE8 standards-only mode is what I would target. Then I guess if users need to support IE8 in non-standards mode they could just polyfill querySelectorAll.

Obviously the original methods would stay the same way in terms of supporting IE8, the requirement would only be for this new functionality.

If you don't think this library's core should support multiple elements, or if features need to support all modes of IE8 then I'll just fork the library. But I thought I'd see if there was interest in adding this to the main library (with the IE8 caveats) before rewriting it for myself.

[0] http://web.archive.org/web/20171004213917/https://msdn.microsoft.com/en-us/library/ff462057.aspx#selectorapi (The Selectors API is defined as part of the Selectors API specification and is only available to Web pages displayed in IE8 standards mode)

[bcherny]

Hi @swang! Can you talk a little about the motivation for this? Why would you want a single event listener instead of one for each draggable?

[swang]

My use case would be multiple draggable elements sitting under the same container. E.g. Being able to move pieces on a chess board.

Generally speaking delegating events to the container (a parent element) should use less memory than assigning events to each individual element. I'm assuming it's also quicker to instantiate that one event rather than multiple events. I've tried this w/ click events, but may also have to test mousemove events to see if there is still the same improvement.

So if I have a page that has several different chessboards that show different scenarios. Instead of having to create an event for every piece of every board. I can just define one listen event delegator to handle it.

Doing this also allows me to add/remove draggable elements without having to redefine a new draggable instance each time an element is created since the event delegate handles it.

[bcherny]

Generally speaking delegating events to the container (a parent element) should use less memory than assigning events to each individual element.

This is not really the case with modern browsers, and hasn't been for some time. If you run a benchmark, you'll see there is no difference between the delegated and non-delegated versions.

I'm assuming it's also quicker to instantiate that one event rather than multiple events

Maybe by, like, nanoseconds? Have you tried profiling this to get some real numbers?

This doesn't seem like a good use case to me. If you can produce a benchmark that shows an improvement with delegation, I'd be more than happy to support this.