Plotly.js: texttemplate

Created on 29 Apr 2019 · 11Comments · Source: plotly/plotly.js

This idea keeps coming up as we discuss various questions... Here's an issue for it!

We should have a texttemplate attribute wherever we accept text or textinfo, with similar semantics as hovertemplate.

feature

Source

nicolaskruchten

👍1

Most helpful comment

More precisely in https://github.com/plotly/plotly.js/pull/3865#issuecomment-493499535

etpinard on 15 Jul 2019

👍2

All 11 comments

Ok so here are the affected traces/components:

$ find . -name "attributes.js" -exec ack -l "\s(textinfo|text):" {} \;
src/traces/box/attributes.js
src/traces/funnel/attributes.js
src/traces/violin/attributes.js
src/traces/pointcloud/attributes.js
src/traces/sunburst/attributes.js
src/traces/funnelarea/attributes.js
src/traces/scatterpolar/attributes.js
src/traces/contourcarpet/attributes.js
src/traces/splom/attributes.js
src/traces/indicator/attributes.js
src/traces/waterfall/attributes.js
src/traces/scatterpolargl/attributes.js
src/traces/mesh3d/attributes.js
src/traces/histogram/attributes.js
src/traces/ohlc/attributes.js
src/traces/scattergeo/attributes.js
src/traces/candlestick/attributes.js
src/traces/cone/attributes.js
src/traces/scattergl/attributes.js
src/traces/surface/attributes.js
src/traces/bar/attributes.js
src/traces/choroplethmapbox/attributes.js
src/traces/pie/attributes.js
src/traces/streamtube/attributes.js
src/traces/volume/attributes.js
src/traces/barpolar/attributes.js
src/traces/scatterternary/attributes.js
src/traces/isosurface/attributes.js
src/traces/choropleth/attributes.js
src/traces/scattercarpet/attributes.js
src/traces/contour/attributes.js
src/traces/densitymapbox/attributes.js
src/traces/scattermapbox/attributes.js
src/traces/scatter/attributes.js
src/traces/scatter3d/attributes.js
src/traces/heatmap/attributes.js
src/components/annotations3d/attributes.js
src/components/colorbar/attributes.js
src/components/annotations/attributes.js

antoinerg on 12 Jul 2019

More like:

// pie-like traces
src/traces/pie/attributes.js
src/traces/sunburst/attributes.js
src/traces/funnelarea/attributes.js

// bar-like
src/traces/bar/attributes.js
src/traces/funnel/attributes.js
src/traces/waterfall/attributes.js

// scatter-like
src/traces/scatter/attributes.js
src/traces/scatterpolar/attributes.js
src/traces/scatterpolargl/attributes.js
src/traces/scattergeo/attributes.js
src/traces/scattergl/attributes.js
src/traces/scatterternary/attributes.js
src/traces/scattercarpet/attributes.js
src/traces/scattermapbox/attributes.js
src/traces/scatter3d/attributes.js

// not sure ?
src/traces/indicator/attributes.js

A lot of traces have text as simply an alias for hovertext, so they don't need textinfo.

I don't think textinfo is necessary for components like annotations as they don't have any data arrays (e.g. %{y}) associated with them.

etpinard on 12 Jul 2019

👍1

... and we can probably do :ok_hand: w/o adding texttemplate for all the scatter* traces in the first iteration.

So that leaves 6 trace types: pie, sunburst, funnelarea, bar, waterfall and funnel.

etpinard on 12 Jul 2019

❤1

In the context of hovertemplate, should the variable text be given the value of the compiled texttemplate when it's available or should it only point to the value in text?

antoinerg on 15 Jul 2019

Thanks for pointing this out!

should the variable text be given the value of the compiled texttemplate when it's available or should it only point to the value in text?

I think pointing to the value in text will be sufficient. That is,

{
  text: '%{label} %{value}',
  hovertemplte: '%{text}'
}

should show %{label} %{value} (i.e. the raw un-templated string), as it would be easy enough to set:

{
  text: '%{label} %{value}',
  hovertemplte: '%{label} %{value}'
}

We had a similar discussion in https://github.com/plotly/plotly.js/pull/3865

etpinard on 15 Jul 2019

👍1

More precisely in https://github.com/plotly/plotly.js/pull/3865#issuecomment-493499535

etpinard on 15 Jul 2019

👍2

... and we can probably do w/o adding texttemplate for all the scatter* traces in the first iteration.

So that leaves 6 trace types: pie, sunburst, funnelarea, bar, waterfall and funnel.

Initial implementation for those 6 traces on this branch: https://github.com/plotly/plotly.js/compare/texttemplate

Note that I'll remove texttemplate_tests.js and insert the tests into each trace's test file.

antoinerg on 16 Jul 2019

That's a very :muscle: first attempt @antoinerg !

I like the way you put some of the logic in Drawing.textPointStyle. So DRY!

A few comments:

now that trace._meta is handled in Drawing.textPointStyle, we could potentially cut a few lines like this block

https://github.com/plotly/plotly.js/blob/1cf8a8576ca729e48471b3c3a23e3c46d551b3aa/src/traces/pie/plot.js#L208-L210

see https://github.com/plotly/plotly.js/pull/3865 for more potentially redundant trace._meta blocks.

We'll have to rename Lib.hovertemplateString to e.g. Lib.traceTemplateString or Lib.templateStringWithData or maybe we could combine it Lib.templateString?
We should make sure traces that have textinfo and texttemplate do not coerce textinfo when texttemplate is non-empty, similar to

https://github.com/plotly/plotly.js/blob/218a9195832aab94b1d8bd0ca4653c159d2f25ce/src/plots/plots.js#L1294

You wrote "TODO: calcTextinfo should build a texttemplate pass it to calcTexttemplate()". That's interesting, I was thinking about doing the same in our _module.hoverPoints methods to DRY things up. But we should be careful here. creating a template string than parsing it must be slower than simply creating a string from (text|hover)info flags. How much slower, I don't know. It would be interesting to benchmark this e.g. try plotting a trace with 1e4 with a texttemplate and check how much slower that is compared to with just a text array.
The jasmine tests you wrote look good, but I would prefer seeing texttemplate in action in one or multiple mocks.

etpinard on 16 Jul 2019

👍1

We'll have to rename Lib.hovertemplateString to e.g. Lib.traceTemplateString or Lib.templateStringWithData or maybe we could combine it Lib.templateString?

I think it should have template, string and format in its name. Its main difference with Lib.templateString is that it supports number formatting (as well as default formats). So, what about Lib.templateFormatString?

cc @etpinard

antoinerg on 17 Jul 2019