-
Notifications
You must be signed in to change notification settings - Fork 11.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improvements to tooltip positioners #9944
Conversation
I initially passed the Chart element as the third parameter to the positioner; however, Scale and LegendElement elements expose `this.chart`, and sample code for positioners used `this._chart`, so documenting the chart member and giving it a public name seems to make more sense.
Any suggestions on how to resolve the Ubuntu CI test failure? The test suite works when I run it locally on Windows and macOS. I'm having trouble getting a local Ubuntu environment to work. |
This is a common failure, that I guess has something to do with the load of the action runners. I'll trigger a re-run to see if it fails in the same spot again. |
In the re-run windows CI failed, which is even more common (as its slower). You'll need to update the example, so lets see how it goes after that commit. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noticed couple more small things
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @kurkle's comments
See #9930 for background. Specific changes:
Chart
instance available to positioners. I initially thought I would pass it in as a third parameter; however, I realized it was already available asthis._chart
, and the position sample uses that.this._chart
feels like a private or protected member, and theScale
andLegendElement
elements both have achart
member, so I renamed the Tooltip element's_chart
tochart
to make it consistent and obviously public. I left a_chart
reference in place, in case any end-user code followed the sample code, to preserve backward compatibility....Map
, similar toInteractionModeMap
, and add documentation on how to keep type safety.this
parameter.Chart.registry.getPlugin('tooltip')
seemed harder than necessary, and it's not what the sample did, and it's not as TypeScript-friendly, so I replaced it with importingTooltip
.Feedback welcome.
A question: I noticed some inconsistencies in type names:
Legend
by the TypeScript type definitions. It creates instances of a JavaScript class calledLegend
, extendingElement
, whose type is defined in TypeScript asLegendElement
, extendingElement
....Element
and extendElement
.Tooltip
by the TypeScript type definitions. It creates instances of a JavaScript class calledTooltip
, extendingElement
, whose type is defined in TypeScript asTooltipModel
, extending nothing.The naming differences between JavaScript and TypeScript aren't ideal, but they're consistent. The differences between
LegendElement
andTooltipModel
seem inconsistent, so I wondered about addressing them. I updatedTooltipModel
to extendElement
, but I wondered if it should also be renamed toTooltipElement
. That would break backward compatibility for type definitions; it's not too unusual for me to have to tweak my types after minor-version updates, so this may be tolerable for a SemVer-minor release. If you'd like for me to renameTooltipModel
toTooltipElement
(and optionally makeTooltipModel
a deprecated alias), either in this PR or another, please let me know.Fixes #9930.