V2.0 dev tooltip refactor

[tannerlinsley]

This refactor basically deprecates the old tooltip templating system in favor a more hook-like template callback system.

Further documentation needs to be written, but basically tooltips are split up into a few parts:

-beforeTitle
-title
-afterTitle
-beforeBody
-beforeLabel, label, afterLabel
-afterBody
-beforeFooter
-footer
-afterFooter

These hooks are simple function callbacks that are passed relevant information. Each scale is equipped with built-in getters for labels and values, and a system-wide default is in place for both single and label hover modes that make the title what it is.

There is no footer by default, and all internals are discouraged from using any before or after prefixed callbacks leaving them open for users to override. Of course, users can override the main callbacks as well.

This new system will easily allow for “totalizer rows” in footers, meta information, or whatever you can imagine in the tooltip (other than images and complex data). If it’s textual, you can put it in the tooltip.

[etimberg]

Going to play with this now

[etimberg]

@tannerlinsley the only thing I thought of was allowing splitting lines with either \r | \n | \r\n. getFooter already returns an array, so it would be fairly easy to simply split each item on new lines as it goes in. This would allow users to create more complex tooltips. Thoughts?

[tannerlinsley]

Or they could return an array of lines.
On Sat, Oct 17, 2015 at 9:07 AM Evert Timberg [email protected]
wrote:

@tannerlinsley https://github.com/tannerlinsley the only thing I
thought of was allowing splitting lines with either \r | \n | \r\n.
getFooter already returns an array, so it would be fairly easy to simply
split each item on new lines as it goes in. This would allow users to
create more complex tooltips. Thoughts?

—
Reply to this email directly or view it on GitHub
#1542 (comment).

[etimberg]

They could, we'd just need to make sure we detect if the return is an array. Other than that, I think this is good to go.

[etimberg]

@tannerlinsley I started to write some docs on this, but ran into some issues with the labels & titles for time / linear x scales. Seeing if I can work through them today.

Edit: Also seeing an issue where the points highlight for all datasets, but then tooltips only show for the single item (using the line sample as a test here)

Edit2: We may also need to consider that not all items are on the same x axis. This makes highlighting all things at the same point hard if the mode is not single because we don't really know what the best title to display is (rare case, but could happen)

[tannerlinsley]

Yeah I'm not sure if it was the best move but I separated the tooltip and hover modes and actions. This would make it possible to have a tooltip be based on a label or dataset but allow the user to perform actions per point or bar click. What do you think? Too much?

And yes, there is a case when the label or dataset axes won't line up all together. I'm thinking at least in the time scale. In this case the scale can offer its own method to determine which points are "active" or they could just use single no matter what. Either way?

[etimberg]

Yeah, I think overall that's a good decision to split up the hover mode & tooltip mode. I noticed a problem with the label mode. I'm hacking in it now, hopefully gonna make some progress. I want to add some tests in as well.

[tannerlinsley]

Awesome. Now that I think of it. We'll probably want overrides on the scale types for some of the shared methods like getLabel and getValue.

[etimberg]

@tannerlinsley I already have getLabelForIndex factored out into each scale. I can check that in momentarily