Repository navigation
Template strings in hover data #3007
Description
This could include both attributes that exist in the trace
trace.hovertemplate = '{text}<br>{marker.size} Items<br>{y} Dollars'
But also data that is computed on-the-fly by plotly.js, like the bin widths:
trace.hovertemplate = 'The number of people between the age of {binleft} and {binright} is {bintotal}.'
This means you could express the existing box and violin text with some type of hovertemplate
This could span across traces, like the hover data on stacked bars
trace.template = 'This represents {trace.y} out of {data.total}'
Or one day, perhaps even trace level computations, like the sum of the area
texttemplate = 'The sum of the money is {trace.sum}'
Activity
chriddyp commentedon Sep 13, 2018
I believe this ties in to the parcoords PR, in customizing the different types of computed data to display (cc @jonmmease)
etpinard commentedon Sep 13, 2018
Very related to #1919 (more precisely https://github.com/plotly/plotly.js/pull/1919/files#r130172295), where Ricky added
nameformatto allow groupby trace to be names via templates.The syntax uses
%{}to denote values, so we would have:nicolaskruchten commentedon Sep 14, 2018
In terms of the types of output that would be permitted by this, here's an example:
nicolaskruchten commentedon Sep 14, 2018
Note that we'll likely need to bake in some kind of
printf-style number formatting here as well to control precision, separators etc.nicolaskruchten commentedon Sep 21, 2018
Here's how Highcharts does it:
etpinard commentedon Sep 21, 2018
Ha poor Highcharts. Using
${}must lead to 🤕 for people using ES6 template strings.nicolaskruchten commentedon Sep 21, 2018
;) I was mostly pointing at the way they encode separators and precision
alexcjohnson commentedon Sep 21, 2018
Right, that's essentially the same
sprintfmodel that python uses, and that we pulled from d3 and already use for various other contextsplotly.js/src/plots/cartesian/layout_attributes.js
Lines 510 to 517 in 2a3dc26
antoinerg commentedon Oct 4, 2018
Should I go ahead and do as Highcharts does: if a variable name is followed by a semicolon, use the remainder as the d3 format string?
${variable_name:d3_format_string}
@nicolaskruchten @etpinard @chriddyp @alexcjohnson
etpinard commentedon Oct 5, 2018
Please don't! We should use the same syntax as in #1919
etpinard commentedon Oct 5, 2018
i.e.
%{}not${}which conflicts with es6 template strings.nicolaskruchten commentedon Oct 5, 2018
... but the idea of
:then formatting-language sounds fine to me :)nicolaskruchten commentedon Oct 5, 2018
Re the syntax of the variable names, the original issue description contains both
yandtrace.y... should we always usetrace.<whatever>for all trace values, so that we can leave the door open to computed values namespaced underdata.totalorcomputed.binleftor whatever?etpinard commentedon Oct 5, 2018
I'd vote staying "in-trace" e.g. using
ynottrace.y. If users want to compute cross-trace total or other statistics, they could fill those incustomdatacombined with a template string of e.g%{customdata.total}nicolaskruchten commentedon Oct 5, 2018
Oh i meant for stuff that plotly computes... like binleft/binright/total (for stacked bars) etc
etpinard commentedon Oct 5, 2018
That would imply exposing some our internal API (mostly from
gd.calcdata) to users, which probably isn't a bad idea, but making that robust will require a pretty big effort.Other example of "computed" values, box
q1,median,q3, histogram "heights". Violinkdeis a funny one, as its hover value, isn't even stored ingd.calcdata, it is computed on hover.nicolaskruchten commentedon Oct 5, 2018
right, but right now those make their way into hovertext, so it would be nice to be able to replicate the current hovertext using the new language... i.e. if you like the 'median' but you want to change the way that number is displayed?
alexcjohnson commentedon Oct 5, 2018
Lets just insert these values - per trace type - into the same namespace as the regular trace attributes, and deal with combining the two in the respective hover routines. We don't want to use the same clipped names as in
calcdataand anyway, as @etpinard points out, that's not even complete. We can describe these options inattributes.hovertemplate.descriptionfor each type, like "You can refer to any trace attribute, and if that attribute is an array we pick out the value being hovered on. In addition, box traces support calculated attributes min, lowerfence, q1, median, mean, stddev, q3, upperfence, and max"Box and violin have an extra challenge though: this syntax assumes there's only one kind of hover label for a trace. When you have separate labels for each level of the box, each one could in principle get its own formatting. What if you think min and max are obvious so you want only the numbers there, and for quartiles you want
%{q1} (25%)and%{q3} (75%)? Do we need to make a separate template attribute for each of these (hovertemplates: {q1: '...', q3: '...', ...}?)Also an issue for finance types using #2959, and scatter types with
hoveron: 'points+fills'.And one more question: currently the hover label formatting can depend on hover mode and occasionally on other traces that also generate hover data. So in "compare" mode normally you only get y data in each trace hover label, and x data sits in the "common label" on the x axis. But in "closest" mode both x and y are in the trace hover label and there is no common label. Occasionally other traces influence this, like if in compare mode if you make two hover labels but they don't quite share the same x, you may get a common label, and only y data in labels for traces that match the common label, but traces that don't match (but are still close enough to generate a hover label) will get both x and y in their labels. So do we just ignore this distinction when there's an explicit
hovertemplate? Or do we accept two variants of the template somehow? I guess I'm leaning toward ignore but we should be clear about it.