Support text templates for shape labels

[emilykl]

Add support for text templates in shape labels.

Add a text template property to shape.label, with support for displaying variables which are updated automatically based on the shape's properties -- for example, the x/y coordinates of a rectangle or the slope of a line.

This feature depends on #6454 (Support adding text labels to lines and shapes).

Proposed API

• Add a shape.label.texttemplate property
• Template string format identical to hovertemplate / texttemplate, where variables can be included in the string using the syntax %{variable}.
  • Number format can be specified using d3-format's syntax
• A limited number of variables are supported, including at least:
  • Shape properties x0, x1, y0, y1
  • Calculated value slope
  • Possibility to include other variables
• Displayed text is updated in real time as values change, including during drag

Partnership

Development of this feature is sponsored by Volkswagen's Center of Excellence for Battery Systems.

[JulianWgs]

Hey @emilykl, it is important that the slope value is scalable. We are handling timeseries data and sometimes the the slope should be measured per second or per minute. This should only be configurable via plotly.py.

[emilykl]

Good point @JulianWgs .

@alexcjohnson Any thoughts on how unit conversions could be achieved? For timeseries, is it possibly covered by d3 time formatting? https://github.com/d3/d3-3.x-api-reference/blob/master/Time-Formatting.md ?

More generally, could it make sense to support applying a multiplication factor to the slope value?

[emilykl]

Looping in @ndrezn here as well

[alexcjohnson]

I think the multiplication / division solution is the best here. Right now IIRC we support format strings in text templates, like %{x:.3f}, let's just put the operation before the colon (if there is one) so %{slope*60000:.3f}.

Does it make sense what numbers you'd want to use here? 60000 is msec/min, so would be used if you want your data in units of /min, since internally date data is represented as msec. We could try and come up with ways to name the units of ∂x and ∂y so you don't have to figure out the numbers, but that feels like it may be more confusion than it's worth, and we'll need arbitrary numbers anyway in order to cover all the edge cases people might think of.

@emilykl if we're just doing <field><operation><value>:<format> we can easily write a purpose-built parser from scratch. But if we ever want to do anything more flexible there's a relatively lightweight one we built for Dash Table here and here that could be ported over. It looks more complex than it is 😉 - if we get to that point I can help.

[JulianWgs]

It's already confusing to me. Do you want to build a unit parser?

Does it make sense what numbers you'd want to use here? 60000 is msec/min, so would be used if you want your data in units of /min, since internally date data is represented as msec. We could try and come up with ways to name the units of ∂x and ∂y so you don't have to figure out the numbers, but that feels like it may be more confusion than it's worth, and we'll need arbitrary numbers anyway in order to cover all the edge cases people might think of.

Imho it is sufficient to stick to the <field><operation><value>:<format> format. For our usecase the operators / and * are enough. Then you might port over the parser from Dash Table in a follow-up Pull Request. I don't think that would be too much double-work and the first implementation would be done sooner (which is important to me). Is this okay for you?
@alexcjohnson @emilykl

[alexcjohnson]

@JulianWgs that's great, thanks for the feedback. Sounds like we're in agreement. <field><operation><value>:<format> where <operation> can either be * or / and <value> is a literal number.

For slope I can't think of any use case for more complex transformations. I could imagine for coordinate values maybe you want scaling and offset, like to convert between ºC and ºF, but there's no need to add that now.

[emilykl]

I agree, <field><operation><value>:<format> sounds like the sweet spot in terms of effort vs. payoff and covers @JulianWgs 's use case. Not sure we want to open the can of worms of supporting arbitrary calculations.

[mosaikme]

Hello thanks for this implementation, i wonder if its possible to add percent calculation ?

I wanted to try to add this function. But the codebase is way to profesional for me, No way i can make a good PR for this.

I started to try to add this , but i dont even get , to the testing of this. Because like i said the codebase is way over my programming skills.

tying to add this...

I think the best would be be allowing this in direct in the texttemplate for example : "xPCT: %{ ( (x0 / x1) -1 ) * 100}" this would give us so much freedom.

[alexcjohnson]

@mosaikme that's certainly a nice use case, but it seems to me a little too specific to add a dedicated field for ((x0 / x1) - 1) * 100 or even ((x0 / x1) - 1) and let the user multiply by 100 with the existing capability. This would be better done with a more general syntax parser as I mentioned in #6511 (comment).

Certainly not a simple addition, and unfortunately this isn't really on our roadmap any time soon but if you or anyone else is interested in sponsoring it we'd be happy to discuss.