RQ: Enhancement request on drag callBacks / updateData

[bdorninger]

Describe the bug
Not a bug....
Currently, drag can be limited by the onDrag callback returning false.
On weakly performing devices and/or quickly done drag interactions, this may result in inconvenient user experience, because drag is stopping before an intended limit.

To Reproduce
Limit drag within the callback, switch on CPU throttling and/or do a swift drag of a datapoint.

Expected behavior
Regardless, how fast the drag is made, the dragged point shall align to the intended limit, if pointer is moved beyond that limit

Proposed Change
Allow the onDrag callback to return not just false, but optionally a datapoint. A little like your magnet.to function. But the magnet is applied too late for my purpose
Just a quick sample code snippet, how I would like to see it
At the end of updataData:

........
...
..
if (!callback || typeof callback === 'function') {
      const ret = callback(e, curDatasetIndex, curIndex, dataPoint);
      if (ret != undefined && typeof dataPoint === typeof ret) {
        chartInstance.data.datasets[curDatasetIndex].data[curIndex] = ret;
        chartInstance.update('none');
      } else if (ret !== false) {
        chartInstance.data.datasets[curDatasetIndex].data[curIndex] = dataPoint;
        chartInstance.update('none');
      }
    }

Could also be restricted to the onDrag callback, but I suppose that needs more code changes, since you do not distinguish between the different configurable callbacks. But using this for endDrag as well, could make the magnet.to obsolete

If this sounds feasible for you, I could issue a PR.

[bdorninger]

Any comment on this, Chris ?

regards,
Bernhard

[chrispahm]

Sorry, super busy right now ☹️

I wanted to review #86 done by @artus9033, who did a great job improving the code quality of this project together with the added benefit of type annotations. Maybe you can have a look as well and probably issue the PR as a follow up of the code-cleanup?

Another thing I have to get done before accepting PRs is finishing the test cases. The possible combinations of options the plugin provides today by far exceed what I originally intended, so I think we might even want to consider unit tests...