texttemplate vs hovertemplate

[nicolaskruchten]

This pen https://codepen.io/nicolaskruchten/pen/YzzXwdL shows some differences between texttemplate and hovertemplate, specifically that %{y} in texttemplate doesn't seem to pick up the formatting from the yaxis ticklabels the way hovertemplate does.

[etpinard]

Looking at #4071, I found:

• texttemplate with date formatting #4071 (comment)
• texttemplate with date formatting #4071 (review)

that discussed similar things, but nothing on axis attributes having an effect on the default texttemplate output - @antoinerg do you remember discussing this?

---

I'd call this bug, axis tickformat, tickprefix and ticksuffix should be considered in texttemplate. Internally, this means using Axes.tickText everywhere.

[antoinerg]

Mmm... that is unfortunate indeed. The code path a value takes before reaching texttemplate and hovertemplate is a bit different hence the difference. We should aim to close the gap.

I'd call this bug, axis tickformat, tickprefix and ticksuffix should be considered in texttemplate. Internally, this means using Axes.tickText everywhere.

I agree that the default labels should contain those 3 tick properties.

[nicolaskruchten]

Is there any case for not declaring absolutely that they should always be equal, not just with those three properties but all properties?

[antoinerg]

Is there any case for not declaring absolutely that they should always be equal, not just with those three properties but all properties?

If I remember correctly, by defaults hover labels may/should have more precision than displayed text.

[nicolaskruchten]

I seem to recall discussing this, yes.

[nicolaskruchten]

All in all this is a wicked feature already :)

[etpinard]

@antoinerg I think I found a fix for this issue - ok if I assign myself this one?

[antoinerg]

@antoinerg I think I found a fix for this issue - ok if I assign myself this one?

Sure go ahead :) Thanks for taking this on

[etpinard]

I probably won't have the time to make a PR to fix this bug for all traces that support texttemplate before my vacation, so here's some info I gathered about this problem.

---

There are currently four different texttemplate "pathways" used currently:

• bar, funnel and waterfall traces format labels and call Lib.texttemplateString inside bar/plot.js
• pie/funnelarea and sunburst/treemap format labels and call Lib.texttemplateString from their formatSliceLabel routine
• scatter, scattercarpet, scatterpolar, scatterternary and scattergeo call Drawing.textPointStyle via Scatter.styleText
• scatter3d, scattergl, scatterpolargl and scattermapbox call Lib.texttemplateString in their "convert" step

---

Fixing this bug here for bar, funnel and waterfall traces is relatively easy: we simply need to copy the labelLabel and valueLabel formatted values

plotly.js/src/traces/bar/plot.js

Line 595 in fbfadbe

obj.labelLabel = formatLabel(cdi.p);

plotly.js/src/traces/bar/plot.js

Line 601 in fbfadbe

obj.valueLabel = formatNumber(cdi.s);

to xLabel and yLabel depending on the orientation.

---

pie, funnelarea, sunburst and treemap appear unaffected by this bug. Their texttemplate formatting appears equivalent to their hovertemplate formatting.

---

All the scatter* traces appear affected, example: https://codepen.io/etpinard/pen/pooWyMg

To fix the scatter case, we'll need to pass xLabel and yLabel to Lib.texttemplateString as formatted by Axes.tickText similarly to how we fill in xLabel and yLabel during hover.

plotly.js/src/components/fx/hover.js

Line 1424 in fbfadbe

d.xLabel = ('xLabel' in d) ? d.xLabel : Axes.hoverLabelText(d.xa, d.xLabelVal);

plotly.js/src/components/fx/hover.js

Line 1428 in fbfadbe

d.yLabel = ('yLabel' in d) ? d.yLabel : Axes.hoverLabelText(d.ya, d.yLabelVal);

(note that Axes.hoverLabelText calls Axes.tickText internally)

To fix the scatterternary case, we'll need to pass aLabel, bLabel and cLabel

plotly.js/src/traces/scatterternary/hover.js

Lines 52 to 54 in fbfadbe

	newPointData.aLabel = Axes.tickText(ternary.aaxis, cdi.a, 'hover').text;
	newPointData.bLabel = Axes.tickText(ternary.baxis, cdi.b, 'hover').text;
	newPointData.cLabel = Axes.tickText(ternary.caxis, cdi.c, 'hover').text;

For the scattergeo, lonLabel and latLabel

plotly.js/src/traces/scattergeo/hover.js

Lines 67 to 68 in fbfadbe

	pointData.lonLabel = Axes.tickText(ax, ax.c2l(pointData.lon), 'hover').text;
	pointData.latLabel = Axes.tickText(ax, ax.c2l(pointData.lat), 'hover').text;

... and so on.

In brief, the logic here in Drawing.textPointStyle

plotly.js/src/components/drawing/index.js

Lines 705 to 709 in fbfadbe

	if(template) {
	var pt = {};
	appendArrayPointValue(pt, trace, d.i);
	text = Lib.texttemplateString(text, {}, gd._fullLayout._d3locale, pt, d, trace._meta || {});
	}

is not sufficient.

---

Now, if we agree that the default texttemplate formatting should be the same as the default hovertemplate formatting everywhere (i.e. with the same number precision), we should probably start thinking about ways to reuse the same coordinate-to-label formatting functions for both hover and texttemplate formatting.

I'm thinking either adding a new trace module method (e.g. _module._formatCoords) or add format functions to the trace's corresponding fullData[i] objects e.g. during supplyDefaults

// in scatterternary/defaults.js
trace._aFormatFn = function(cdi) { return Axes.tickText(ternary.aaxis, cdi.a, 'hover').text; };

With a bit more work, perhaps we could even generalise _module.eventData so that it also formats the coordinates.

Oh well, having all the per-trace coordinate formatting logic in one place should be a big win.

[nicolaskruchten]

OK to bump to 1.52

[etpinard]

OK to bump to 1.52

Sure, but this can be done in a 1.51.x patch release also.

[etpinard]

Here's my WIP branch:

https://github.com/plotly/plotly.js/compare/texttemplate-formatting-fixes

Anyone should feel free to pull it down and add commits to it during the next two weeks.