Pass customdata to 'fill' or trace itself.

[marcodlk]

I am a plotly.py/Dash user and recently ran into a little blocker regarding the customdata feature.

The situation:
I am using go.Scatter with options
name='trace_name', mode='lines', fill='toself', hoveron='fills+points', customdata=some_preset_data, text=some_preset_text
to make traces that each represent a polygon.

Limits of current customdata feature:
The hoveron='fills+points' option allows the user to see text and interact with customdata when hovering/clicking on points, which is great. However, when hovering over the fill (which gives the feeling of representing the trace itself), the user is limited to seeing the name property ('trace_name' here) on hover and only being able to interact with the curveNumber of the trace - customdata and text don't show up because they are 'unique' to each point.

Feature request:
As a user, I would like to be able to attach customdata and/or text to fill elements or the trace itself. Purely from a user point of view, there seems to be a disconnect there, where the 'fills' and 'points' in the hoveron='fills+points' options have highly different levels of hoveron customizability/functionality.

Unfortunately, I am not a javascript programmer and cannot add much (if anything) to how this would be implemented, but I was directed here from the plotly/dash forum as this seems to be an issue pertinent to plotly.js itself.

Relevant plotly/dash forum:
https://community.plot.ly/t/dcc-graph-only-curvenumber-is-showing-up/9225

[etpinard]

That would be nice for sure! Thanks for writing in.

The hardest part about this here is to find a suitable API. For point data, coordinates and fields like customdata (and hovertext for that matter) match 1-to-1. For fills, the relationship isn't bijective. We could of course tell users to make their customdata match the number of polygons or more technically the number of null in their coordinates arrays plus one. Something like this has been proposed already for other things like #147. But then, what should we do for hoveron: 'fill+points'? We won't be able to honor both the customdata to polygon and customdata to coordinate maps. So perhaps the solution is to add a new field something like customfilldata? But that's sounds a little dirty. I hope we can find a cleaner solution.

[marcodlk]

Would it be possible to have something like:

customdata={
    'points': customdata_for_points,
    'fill': customdata_for_fills
},
customdatamode='points+fills'

Ignoring the lazy naming, the point is that you could use an additional variable to set the mode for interpreting the customdata argument. By default it could be 'points', meaning it would follow current behavior allowing backwards compatibility, but at the same time you could set new modes that allow for new features such as customfilldata (without making a new tightly coupled kwarg)

Sorry, I can only see this through the python lens, but hopefully it can make some sense in JS as well.

[alexcjohnson]

One thing we could do without changing the API at all is add the customdata/text for all points in the polygon, as an array, to the event data. The data would still be specific to each polygon, in the case of a disjoint trace, and you'd be able to distinguish point and fill events by the array structure.

[slishak]

Maybe a generic solution could be to add a second trace attribute like customtag or something, that acts as a scalar version of customdata? In other words, a way to attach custom data to a trace, instead of/as well as a data point.

I have a use case where this would be useful: I have a heatmap where the data is updated by a restyle component, but when I listen to click events from the plot I want to know which restyle option has been selected by the user. I've tried assigning a customdata field that's updated by the restyle, but I've just repeated the same data for every coordinate on the heatmap, because the data I want to receive is for the whole trace, not for the individual point that's been clicked. This is quite inefficient because there are a lot of points in the heatmap, although even this method doesn't work because I can't receive customdata from a heatmap in a Dash callback (https://community.plot.ly/t/plotly-dash-heatmap-customdata/5871)

[gvwilson]

Hi - this issue has been sitting for a while, so as part of our effort to tidy up our public repositories I'm going to close it. If it's still a concern, we'd be grateful if you could open a new issue (with a short reproducible example if appropriate) so that we can add it to our stack. Cheers - @gvwilson

[ltuijnder]

Hi custom data info on a trace level would be very nice. As this would easily enable custom behavior on trace level. In my case it is custom logic for trace highlighting.

The current options I have:

1. encode information in the uid and then parse it out again when passed back the trace data.
2. Pass on your custom values to customdata and only consider the first value of the data.

Problems with option 1:

• It is abusing the uid attribute that in reality is meant to be a unique id, but it can very well be that custom data I want to attach to traces does not have to be unique between the traces.
• Not all data can easily get serialized into a 1 length string...

Problems with option 2:

• Highly inefficient in case of large amount of data points and it gets worse for each custom data field we are adding.
• Trace might have no data and in that case the custom data is simply also gone! While the trace still exists!

Looking at the trade-offs it seems that option 1 is the best but it feels just so convoluted to start doing custom parsing of strings... While it feels like this could be an easy addition.

Would it not be possible to add for each trace a: "custom_trace_data" which is of type json-object and the end-user is fully responsible on its structure.

Please consider reopening this issue.