chartjs
Intersect mode with filled line dataset should include hovering the fill
Expected behavior
I think it's a common expectation that "intersects" hover mode should include hovering the filled area of a stacked line chart. Hovering the points requires precision, and is unexpected to behave differently the hovering the fill area.
Note: the issue with using intersects="false" is it forces something to be hovered. If the user hovers outside of any dataset, this should not highlight the top one.
Current behavior
You need to hover the precise data points, not filled area
Reproducible sample
https://codepen.io/alexrcoleman/pen/WNJYJzZ
Optional extra steps/info to reproduce
No response
Possible solution
No response
Context
No response
chart.js version
3.3.2
Browser name and version
No response
Link to your project
No response
This can likely be done given that the internals of the line filler were refactored to use Path2D objects. We can use https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/isPointInPath to test the intersections
I think this would be better as an enhancement with a new property like intersectArea
Agreed on a new setting because otherwise it's a breaking change
@etimberg @LeeLenaleee in my opinion, but maybe I'm wrong, sorry, I think that we could use anyway intersect as option without breaking change:
intersect: boolean || 'area';
Anyway, there could be another breaking change (even if we will go to new option) on the exposed function
/**
* Helper function to select candidate elements for interaction
* @param {Chart} chart - the chart
* @param {string} axis - the axis mode. x|y|xy|r
* @param {Point} position - the point to be nearest to, in relative coordinates
* @param {function} handler - the callback to execute for each visible item
* @param {boolean} [intersect] - consider intersecting items
*/
function evaluateInteractionItems(chart, axis, position, handler, intersect) {
Where the intersect it's defined only as a boolean and this will change the signature, I guess. WDYT?
It will be breaking for both in both of your examples.
If you write code that expects it to always be a boolean and it becomes a string suddenly that is a breaking change so in my opinion we can't change this in V4 so it needs to be either a new option or wait till v5
@LeeLenaleee I agree. In the meantime I had a quick look to the code and I see some pain points..
Line element is currently using Path2D but in transient way (it is created and destroyed at every drawing cycle). In my prototype I stored it and works. But we cannot use isPointInArea because the filling is performed by filler plugin without using Parh2d if I am not wrong. Furthermore the interaction must be changed to accept a Line element which is not used as data element (as interaction is expecting) but it is only a dataset element. For hovering probably makes sense (for instance using hover style options) but for interaction with the chart is more complex (for instance tooltip, should show all data elements ?). WDTY? I think v5 is anyway better because it could be a no-simple change.
Agreed on this going for v5 given the changes needed. I wonder if caching the Path2D objects would give us some rendering performance boost. Maybe we could put that into v4.4?
@etimberg I'm not sure if caching the Path2D there will be a performance boost. A Path2D object should be created at every drawing iteration (as is today in the line element) because the path is changing (animation) and, afaik, there isn't any way to reset a Path2D.