Add 'hovertext' attribute in scatter* traces #1523
Conversation
| if(di.tx) pointData.text = di.tx; | ||
| if(di.htx) pointData.text = di.htx; | ||
| else if(trace.hovertext) pointData.text = trace.hovertext; | ||
| else if(di.tx) pointData.text = di.tx; |
There was a problem hiding this comment.
This is what I came up with:
- If trace
hoverinfocontains a'text'flag andhovertextis not set thetextelements will be seen in the hover labels - If trace
hoverinfocontains a'text'flag andhovertextis set,hovertexttakes precedence overtexti.e. thehoverinfoelements will be seen in the hover labels
|
Would love some 👍 s from @alexcjohnson @bpostlethwaite @n-riesco |
|
👍 from me. Besides the use case described by Étienne, I also find, from a user point of view, that |
|
👍 seems clear and I think it covers all use cases. I suppose you could argue for the ability to display BOTH text and hovertext in the hover labels, but that opens a big can of worms just to avoid a bit of duplication in hovertext so doesn't seem like a good idea. Bar and pie could also benefit from this feature. |
Good call. Thanks! |
|
Thanks @n-riesco @alexcjohnson , dropping the |
|
TODO:
|
| }, | ||
|
|
||
| text: { | ||
| valType: 'data_array', |
There was a problem hiding this comment.
@alexcjohnson I just noticed that text for pie is declared as a data_array whereas other trace types have it as a string with arrayOk: true. Was that on purpose? Or should we allow single-value text input for pie traces?
There was a problem hiding this comment.
That was on purpose - though probably never explicitly discussed. My rationale is that text is essentially the x data for pies, and they would be meaningless without this being an array of data. Can you think of a counterexample?
There was a problem hiding this comment.
I agree for the on-graph textinfo: 'text' part. But if someone wants to show the same text piece in all hover labels? But I guess after this PR, hovertext will cover that case.
There was a problem hiding this comment.
Oh sorry, that's label... I still don't see a good usage for a single-value text but perhaps it would be better to define it consistently with other trace types anyway.
test/jasmine/tests/hover_pie_test.js
Outdated
| var labels = d3.selectAll('.hovertext .nums .line'); | ||
|
|
||
| var labels = Plotly.d3.selectAll('.hovertext .nums .line'); | ||
| expect(labels[0].length).toBe(expected.length); |
|
nice. 💃 |
Scatter traces (i.e.
scatter,scatter3d,scattergeo,scatterternaryandscattermapbox) have atextattribute which is displayed on the graph whenmodecontains the'text'flag. Thetextcontent is also displayed in the hover label whenhoverinfocontains the'text'flag.But, what if a user wants to display some text elements on the chart and some other (distinct) text elements in the hover labels? Currently we would have to use two traces to achieve this.
So, I proposed adding a
hovertextattribute. Now it's a little difficult to preserve backward compatible; we should make sure to agree on the details.