Hassle free Zoom (and maybe drag and brush in the future)

[gampleman]

Currently there is a problem with setting up Zoom for SVG content, in that it is quite fragile and doesn't work entirely properly in every situation. We're going to ship a more complex example on how to handle these issues, but I'd prefer to have this be less finicky.

The core problem is that Elm simply doesn't expose the methods we need to get accurate SVG coordinate information from events, so there is a lot fairly convoluted code in Zoom.elm that tries to hack around this limitation, however in principle you can (relatively easily) create situations where this won't work very well.

So one solution to this problem is to continue to put the onus of setting this up on you, our users. As I said, we are planning to ship a more in depth example as well as some more detailed instructions in the module docs. However, the other solution that has occurred to me is to simply hack it. Essentially the idea is to ask users in the module docs to add this snippet of JavaScript somewhere in their application:

function getProperSVGCoordinates() {
  try {
    var node = this.target;
    var svg = node.ownerSVGElement || node;
    if (svg.createSVGPoint) {
      var point = svg.createSVGPoint();
      (point.x = this.clientX), (point.y = this.clientY);
      point = point.matrixTransform(node.getScreenCTM().inverse());
      return [point.x, point.y];
    }
    if (node.getBoundingClientRect) {
      var rect = node.getBoundingClientRect();
      return [
        this.clientX - rect.left - node.clientLeft,
        this.clientY - rect.top - node.clientTop,
      ];
    }

    return [this.pageX, this.pageY];
  } catch (_error) {
    // getters should not throw under any circumstance
    return undefined;
  }
}

Object.defineProperty(MouseEvent.prototype, "_elmVisualizationPointerCoords", {
  get: getProperSVGCoordinates,
});

Object.defineProperty(Touch.prototype, "_elmVisualizationPointerCoords", {
  get: getProperSVGCoordinates,
});

Elm Visualisation would then attempt to decode this property off the event handlers it uses. It already uses multiple (potentially failing) decoders to ensure browser compatibility, so adding another one in the stack wouldn't be a huge deal. This would in turn mean that Zoom would now work perfectly in any context across the whole application without having to worry about using the full range of SVG features.

It would also degrade gracefully, by reverting to the present behaviour if the snippet wasn't present.

However, a major downside is that it is essentially a hack:

1. An Elm package asking you to copy-paste some JavaScript code is kind of gross.
2. It relies on modifying the prototype of a global object.
3. It relies on executing JavaScript code as part of an Elm decoder. In this case it's not any less pure than reading other properties of off an event, but its still a hack of the Elm purity system.

So, I have some questions:

1. Is it worth it? Would you use it (feel free to vote with emoji 👍 / 👎 )?
2. Any ideas on how to make this nicer?

[deciob]

I feel your pain here, it does feel very hacky. Would I use it? If it works and it is a good improvement on the pure elm solution, then I think I would ;)

[AlexChalk]

I am currently picking a data visualization library, and though I'm not sure it's totally fair, this would probably put me off using elm-visualization.

This is mainly because I'm aware Evan wrote interop the way he did to encourage a purer package ecosystem (https://guide.elm-lang.org/interop/limits.html), and I'd worry about running into unknown unknowns further down the road due to an approach that conflicts with the one taken by elm itself.

Type safety/type modelling is also a big part of what got me excited about elm, and I'm inclined to favour solutions that preserve the benefits of that as far as possible.

If it works and it is a good improvement on the pure elm solution, then I think I would

If I was already invested in the library I think I'd do the same, I'd just be concerned about how this looks to prospective new users who haven't yet decided on a solution.

But all that said, I can't back up my gut reaction with substantial evidence, I'm not maintaining the library, and this looks like a great contribution to the community whichever way you decide to go, so thanks for all your work ⭐.

[gampleman]

Well the best solution would be for this to be added to Elm natively! However, I am not holding my breath. Other Elm libraries are doing something similar for the same reasons.

I think your point about considering the optics is a good one though.

I also wonder if maybe being more sneaky about it would be a solution. What I mean is to have this be essentially an undocumented feature. Maybe add a link like "Having issues with accuracy?" which would point to a separate document explaining this "solution"?

🤔

[AlexChalk]

Well the best solution would be for this to be added to Elm natively!

A PR for this wouldn't be accepted? elm/svg does say 'This package should only change to account for new SVG tags and attributes'—sounds like it applies here? I wouldn't want to see users feeling tricked.

[gampleman]

PR is not straightforward as it needs a fair bit of design. For example for Zoom we are using both VDOM events (i.e. events attached to the elements themselves) as well as events coming from elm-browser. So making this work reliably isn't a straightforward change in the way the packages are currently designed.