That's a very 💪 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

Lines 208 to 210 in 1cf8a85

    
           if(trace._meta) { 
        
               txt = Lib.templateString(txt, trace._meta); 
        
           }

see #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

Line 1294 in 218a919

if(!traceOut.hovertemplate) Lib.coerceHoverinfo(traceIn, traceOut, layout);

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.

texttemplate #3816

Description