chartjs / chartjs-plugin-annotation

Annotation plugin for Chart.js
MIT License
607 stars 328 forks source link

Dynamically showing/hiding labels in response to mouse events #589

Closed joshkel closed 2 years ago

joshkel commented 2 years ago

I set up mouse enter and leave events to dynamically show labels when the user mouses over the annotation:

    enter({ chart, element }) {
      if ('label' in element.options && element.options.label) {
        element.options.label.enabled = true;
        chart.draw();
      }
    },
    leave({ chart, element }) {
      if ('label' in element.options && element.options.label) {
        element.options.label.enabled = false;
        chart.draw();
      }
    },

This was based off of the old horizontal-line.html sample.

This worked fine until chartjs-plugin-annotation 1.2.0 - specifically, #547. If I'm understanding correctly, the changes in #547 cause labelVisible to be precalculated so that it no longer responds to changes in enabled.

I tried fixing this by calling chart.update() instead of chart.draw(), but things still didn't work. I think the code is using its options proxy and context to retrieve the original annotation options object, instead of the dynamically updated element options, but I'm not sure that I fully understand how contexts and options proxies work.

I can directly access the original chart options, but that feels ugly (if using TypeScript, due to its optional properties, and if annotations are in an array instead of keyed by unique ID):

        chart.options.plugins.annotation.annotations[0].label.enabled = true;

Is dynamically updating element options supported? What's the proper way to do it?

Thank you.

stockiNail commented 2 years ago

@joshkel there is a sample which is addressing your use case, which is directly access the original chart options:

https://www.chartjs.org/chartjs-plugin-annotation/latest/samples/line/labelVisibility.html

The label is precalculated in order to enable the the animation.

In my opinion the proper way should be to change the original options and invoke the chart.update.

kurkle commented 2 years ago

The element options are the ones resolved at update and get overwritten in update. Animations might update those too. So it's essentially view state of the element and in that sense your approach seems reasonable. I'd rather have things working without the need to call update from a event hook, because it can be an expensive call.

stockiNail commented 2 years ago

@joshkel I have prepared a codepen https://codepen.io/stockinail/pen/abyrGav

Leveraging on context persistence, you can store the status hovered in the context and define enabled option as scriptable.

label: {
  backgroundColor: 'red',
  content: 'Test Label',
  enabled: (ctx) => ctx.hovered,
},
enter(context) {
  context.hovered = true;
  context.chart.update();
},
leave(context) {
  context.hovered = false;
  context.chart.update();
},

This is the way used also in other plugins (see Datalabels).

Of course I agree with @kurkle about the usage of update() which can be expensive but I don't see another way now.

I'm playing with animations configuration in order to enable the usage of labelVisible property. Maybe I can find another way to do it, without invoking update(). Maybe using specific transitions (showLabel and hideLabel).

stockiNail commented 2 years ago

@kurkle I see a potential issue. intersects method is not considering the borderWidth. That means when you are hovering a line with a borderWidth >1, the event is fired only when the mouse is hover the center of the line. Before opening an issue, I'd like to do some additional tests.

kurkle commented 2 years ago

I'll consider this a bug. In a related note, chart.js allows plugins to set args.changed, so the chart can re-render automatically after processing the event completely. This is important when there are many plugins that require re-draws. It gets slow and messy if every plugin does the draw (or update!) in their event handlers.

So I think these handles should be allowed to set/return a flag indicating a redraw should be done.