Enable interaction mode support for events

[stockiNail]

This PR is addressing the discussion #658

This PR is enabling the interaction mode support, similar to CHART.JS.

annotation: {
  interaction: {
    mode: 'nearest' | 'point' | 'x' | 'y',
    axis: 'x' | 'y' | 'xy',
    intersect: boolean
  },
  annotations : ....
}

Similar to CHART.JS because this PR is implementation 'nearest' , 'point', 'x' and 'y' modes (not all the others, more related to dataset elements). The fallback is to chart.options.
For axis option, 'x', 'y' and 'xy' values are supported, if 'r' is set (not supported), the plugin will use 'xy'.

TODO

• box annotation
• ellipse annotation
• label annotation
• line annotation
• point annotation
• polygon annotation
• interaction mode 'x'
• interaction mode 'y'
• types
• documentation

[kurkle]

Looks ok for that use case. Not sure if it is the only use case though, maybe we need interaction modes here too?

[stockiNail]

Looks ok for that use case. Not sure if it is the only use case though, maybe we need interaction modes here too?

make sense to enable the interaction mode. I think we could use nearest (as default) and point (as this PR is implementing), using the same labels of CHART.JS.
Let me know if you would like to implement a subnode (as in CHART.JS) or only a options (interactions). I think the single option could better if we don't add additional options (like in CHART.JS, i.e. intersect and axis).

Furthermore I think we should add this new option to annotation node (valid for all annotations) and not to each single annotation.

What do you think?

[kurkle]

Yes, I think the option should apply to all annotations. It could also fall back to chart.js interaction options, so we'd use the same mode by default. Need to decide what mode is "default" and what mode(s) to implement.

So, I think it makes sense to have a sub-node, and probably would be good to implement the same options too. The other options can be delt with later, but maybe its just some copied code from chart.js that is needed.

Maybe the end result can be generalized so it can be used in chart.js too and thus be available to other plugins.
chartjs/Chart.js#10046 is maybe relevant, though the functions used here would probably be one step lower level than those exposed by that PR.

[kurkle]

This could probably be in v1.4 if we keep the current behavior as default.

[stockiNail]

Yes, I think the option should apply to all annotations. It could also fall back to chart.js interaction options, so we'd use the same mode by default. Need to decide what mode is "default" and what mode(s) to implement.

I think we should leave the current behavior (nearest) as default, to avoid breaking change. Nevertheless I need to go more in deep in interactions code (and implementation) of CHART.JS.

So, I think it makes sense to have a sub-node, and probably would be good to implement the same options too. The other options can be delt with later, but maybe its just some copied code from chart.js that is needed.

👍
I have to admit that I have to study how the other options are really working (intersect and axis) and the impact in this plugin as well.

Maybe the end result can be generalized so it can be used in chart.js too and thus be available to other plugins.
chartjs/Chart.js#10046 is maybe relevant, though the functions used here would probably be one step lower level than those exposed by that PR.

Let me take time to have a look to that PR. I need some days because busy in other stuff.

This could probably be in v1.4 if we keep the current behavior as default.

Yes, we could but maybe it's not so important to release it soon therefore it could wait for version 2 where there are already important updates to do. Anyway, if you agree, let's wait for feedback about version 1.3 and if possible issues will come.

[kurkle]

Yes, we could but maybe it's not so important to release it soon therefore it could wait for version 2 where there are already important updates to do. Anyway, if you agree, let's wait for feedback about version 1.3 and if possible issues will come.

If we can release an enhancement as a non breaking change, we should do it before releasing the breaking changes. That way users can have that enhancement and not need to deal with the breaking changes just yet. Could also provide some feedback that requires another breaking change, which we can then do in v2 instead of v3.

Another thing is the number of changes, in 1.3 we already have quite a lot.

[stockiNail]

If we can release an enhancement as a non breaking change, we should do it before releasing the breaking changes. That way users can have that enhancement and not need to deal with the breaking changes just yet. Could also provide some feedback that requires another breaking change, which we can then do in v2 instead of v3.

Another thing is the number of changes, in 1.3 we already have quite a lot.

Ok for me!!

[stockiNail]

I have started working on the interaction mode.
First feedback is that the default in CHART.JS is always nearest apart of scatter chart which is point.
To whom is using scatter charts, this PR could be a breaking change if we want to fallback to CHART.JS options.

[stockiNail]

I'm not using any API exposes by CAHRT.JS, as starting point. Anyway, having a look to those APIs, it seems to me there are accessing to dataset elements and it seems not configurable. Anyway, put it in my TODO.

[stockiNail]

@kurkle apart the review, there are 2 CC issues:

1. File annotation.js has 253 lines of code (exceeds 250 allowed).: for this issue, I'd suggest to move out the "elements" part in a dedicated file (as we did for scales). Another PR is needed.
2. Identical blocks of code found in 2 locations.: this issue is related to box and label annotations which have got the same inRange method. The solution could be to use the inheritance, creating a "baseBox" annotation (with only inRange method) which will be extended by both annotation.

[kurkle]

@kurkle apart the review, there are 2 CC issues:

1. File annotation.js has 253 lines of code (exceeds 250 allowed).: for this issue, I'd suggest to move out the "elements" part in a dedicated file (as we did for scales). Another PR is needed.

This is fine, we can fix it in another PR.

2. Identical blocks of code found in 2 locations.: this issue is related to box and label annotations which have got the same inRange method. The solution could be to use the inheritance, creating a "baseBox" annotation (with only inRange method) which will be extended by both annotation.

This one can be ignored, reporting duplication of one (or 3) line(s) is just silly.

[stockiNail]

This is fine, we can fix it in another PR.

I'm doing