Plotly.js: 'marker+text' mode for bar charts

[jackparmer]

Currently, we have to make annotations for bar charts because 'markers+text' mode (Reference: https://plot.ly/javascript/reference/#scatter-mode) does not extend to bar charts like this one:

https://plot.ly/javascript/bar-charts/#bar-chart-with-direct-labels

This can be tedious for a large number of bars, especially if someone is using the Web App. It would be nice if 'markers+text' mode existed for horizontal and vertical bar charts.

[etpinard]

having mode: 'makers+text' for bar charts doesn't make sense for as mode: 'text' would be a degenerate text chart.

[etpinard]

I would use textposition instead, similar to what we do for pie charts.

with dflt: 'none' (meaning hover text only).

[jackparmer]

Ah, great points! That's a sweet idea!

[chriddyp]

related: https://github.com/plotly/plotly.py/issues/356

[cldougl]

Cool - thanks for the textposition tip @etpinard !

[ryanlin1986]

This is a productivity boost.

[alexcjohnson]

In fact more pieces of the pie chart text functionality should be replicated here - like textposition='auto' putting labels inside the bars if they fit (or if there's another bar stacked on top), and outside otherwise; shrinking the label if need be when it's displayed inside; insidetextfont and outsidetextfont so you can have differences (usually just different color, like white inside and black outside) in addition to textfont controlling them both.

[etpinard]

Perhaps bar charts with barmode: 'stacl' should show totals: https://github.com/plotly/plotly.js/issues/85

[n-riesco]

@jackparmer @cldougl The PR for #80 is almost completed. I'm planning to work on this issue now.

[n-riesco]

@etpinard @alexcjohnson I have a PR that implements this feature ready for review on my repo.

[etpinard]

Thanks @n-riesco I'll take at your PR before days end. Cheers :beers:

[etpinard]

Done in https://github.com/plotly/plotly.js/pull/1159

[PPPW]

Dear alexcjohnson and etpinard,
Thanks for the explanation, but it seems the three text font options are not working, no matter what numbers I set, the font size stays the same:
https://codepen.io/anon/pen/weNjVP?editors=0010

[etpinard]

@PPPW here's a working version: https://codepen.io/etpinard/pen/RgvJPK?editors=0010

outsidetextfont expects an object with possible keys size, color, and family.

[PPPW]

Dear @etpinard , I wonder could you take a look at this case: it seems if we got a lot of bars, then the font size will be too small:

https://codepen.io/anon/pen/weNjVP?editors=0010

You can change the first line to change the number of bars in the plot. In my example, the font becomes too small. It'll be nice if the font can be as large as the bar, or more visible or tunable. Thanks!

[rreusser]

@PPPW The issue is these lines: https://github.com/plotly/plotly.js/blob/master/src/traces/bar/plot.js?utf8=%E2%9C%93#L352-L354

They constrain the text bounding box to be no larger than the bar, which in this case is a bit too restrictive. If there's a way around it, it's not clear to me. Perhaps this constraint should not be applied if you've explicitly provided a font size. Since the bounding box size isn't known at supply-default-time, I think that would require storing the presence of outsidetextfont.size in an extra private flag, say _outsidetextfontsizespecified, which could then be used to decide whether or not to constrain it. That might be too convoluted. Thoughts, @etpinard @alexcjohnson?

(or another attribute, obv: constrainoutsidetext: true | false. Less magic; more attributes.)

[alexcjohnson]

Perhaps this constraint should not be applied if you've explicitly provided a font size.

Seems reasonable. We could also probably :hocho: the text padding for outside bars, and in the case of a single trace or grouped bars, allow outside text to expand up to the full bar spacing (including the gap between bars). If we did those two, the text in this case (omitting outsidetextfont.size) should automatically get the same size as the axis labels, but on zoom it would still avoid overlaps. But even so there will be edge cases where you want explicit sizing, so I think we should do both.