You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Contrary to docs, "x-axis" mode not equivalent to "index with intersect" #3605
The docs on v2.4 introduce new interaction modes. They state:
x-axis mode (deprecated): Behaves like 'index' mode with intersect = true
Current Behavior
When I replace x-axis with index and intersect=true on a Chart.js 2.4 chart, the behavior is not the same. Specifically, user action (hover or click) that would have activated elements before no longer do so.
Steps to Reproduce (for bugs)
Open this plunk (Typescript) and select file app/app.component.ts from the list left of the main window.
The top chart has hover.mode = tooltips.mode = 'x-axis'. Notice that as you hover the chart, the tooltips open and the chart emits the active element correctly (as indicated by the output under the chart)
The bottom chart has hover.mode = tooltips.mode = 'index' with intersect = true. To see the tooltip and emit the active element, the user has to position the mouse exactly on a datapoint.
Context
I'd like to move away from deprecated properties (mode:'x-axis'), but I don't know how to reproduce my current user interface with the new API. Either the docs are inaccurate or I misunderstood them.
@simonbrunel thank you that was helpful. If you can, could you say a quick note about why we have two sets of options that seem to control the same thing. Meaning why do I need to set both hover.mode and tooltips.mode? Likewise hover.intersect and tooltips.intersect?
My understanding: hover determines which areas of the chart will select which active elements; tooltips determines which areas will trigger tooltips to open. So that if the two settings are mismatched, elements may become active without triggering tooltips, or tooltips may show even though no elements are active.
Please correct me; that was just an educated guess.
Your guess is right, you can control hovering (i.e highlighting elements) and displaying tooltip independently. For example, let's say you have 2 datasets and you want to show the tooltip for data with the same index whatever the mouse is over an element or not ({ tooltip: 'index', intersect: false }) but you want to show the value of the data point under the cursor (as you have in your example) and so highlight this specific element only when over the point ({ hover: 'nearest', intersect: true }).
Activity
simonbrunel commentedon Nov 16, 2016
Looks like a doc typo, I think it should be:
RoxKilly commentedon Nov 16, 2016
@simonbrunel thank you that was helpful. If you can, could you say a quick note about why we have two sets of options that seem to control the same thing. Meaning why do I need to set both
hover.modeandtooltips.mode? Likewisehover.intersectandtooltips.intersect?My understanding:
hoverdetermines which areas of the chart will select which active elements;tooltipsdetermines which areas will trigger tooltips to open. So that if the two settings are mismatched, elements may become active without triggering tooltips, or tooltips may show even though no elements are active.Please correct me; that was just an educated guess.
simonbrunel commentedon Nov 16, 2016
Your guess is right, you can control hovering (i.e highlighting elements) and displaying tooltip independently. For example, let's say you have 2 datasets and you want to show the tooltip for data with the same index whatever the mouse is over an element or not (
{ tooltip: 'index', intersect: false }) but you want to show the value of the data point under the cursor (as you have in your example) and so highlight this specific element only when over the point ({ hover: 'nearest', intersect: true }).http://plnkr.co/edit/XoVrlVWF9FGz1a8mPRwo?p=preview
RoxKilly commentedon Nov 16, 2016
I think I understand. Thanks. I'll let you decide when it's appropriate to close the issue.
etimberg commentedon Dec 7, 2016
docs fixed in #3684