Expose dragging boolean

[EmiPhil]

For my live charts use case I wanted it so that if a user started to drag the live system would stop updating the charts. I couldn't find a way to do that reliably with the current set up so I put in a one liner:

self.isDragging = () => dragging;

which worked.

[leeoniya]

i wonder if just binding to the native dragstart/dragend events would be sufficient to set a flag in app-space?

https://developer.mozilla.org/en-US/docs/Web/API/Document/dragstart_event

otherwise exposing it as a cursor property seems most logical (similar to cursor.lock/cursor.locked).

[EmiPhil]

Yeah that could work for my use case. The one pain point is that right now the real time loop checks if any target chart is dragging to determine if it should update or not.

It just so happens to be the case that if there are multiple charts on screen they are all synced together, so applying the dragstart to any of them would work for all of them, but it would get hard to manage if there was a case where you wanted to know if any of many charts are dragging that aren't synced.

Like for me to go with the dragstart event I would probably just set a variable called isDragging that represents if any chart is dragging and that would feel fine. But it would be a real pita to have to have isChartADragging, isChartBDragging, etc, with an event listener on each.

I'm not sure if there are other use cases for wanting to know the state of dragging beyond my specific one where it would be likely that you would want to individually track isDragging for multiple charts?

[leeoniya]

it's not that much of a pita, really. you'd just need to bind 2 listeners to each chart, keep a Map and toggle some booleans.

another method would be to grab the .select and check its boundingRect on-demand.

all the ways to do this externally are pretty easy. but it's also easy to expose since we track it anyhow, so i'm like 50/50 on doing it. this is a first request for it and there are already ways to do it. let's see if anyone else chimes in.

backburner for now.

[leeoniya]

@EmiPhil ok, this turned out to be necessary for how i wanted cursor sync to work, so you get it for free (u.cursor.drag._x & u.cursor.drag._y). i'm leaving it undocumented for now.

bigger picture though, take a look at the changes in the last 2 commits: 3658103, 31bbf0e.

these close the loop on what i meant in #216 (comment) (relying more on the dynamic dragX and dragY rather than the static ones during sync).

drag.x and drag.y opts are meant to limit what can kind of drags will be recognized/initiated locally, as opposed to a universal lock-out. the latest changes allow for src's behavior to dictate the explicitness/implicitness of the drag in the sync'd charts.

what bugged me about the x/y ranger demo was that it did not y-auto-scale when the actual drag was x only and scale.y.auto was true. it's irrelevant that x and y are allowed, what matters is what kind of drag actually happened. if you dont want auto-scaling on y during an x-only drag, then you need to set the scales.y.auto: false and provide a range and/or initial min/max (see the new commented code in the x/y ranger).

i haven't tested all the other sync stuff yet to see if anything broke, but will later today.