Better schema declarations for array attributes that don't scale with coordinate arrays

[etpinard]

See #1891 for context.

At the moment, axis.tickvals, axis.ticktext, axis.categoryarray, colorbar.tickvals and colorbar.ticktext are listed as valType: 'data_array'. This is causing issues for colorbar.tickvals and colorbar.ticktext as routines that use the output of PlotSchema.findArrayAttributes are expecting those data arrays to scale with the coordinate arrays.

So, as @alexcjohnson points out, maybe we should tag these uncorrelated data arrays in the schema (e.g. colorbar.tickvals would have uncorrelatedArray: true) - which would be a lot more robust than the solution in aa93123

But perhaps, we should make these attributes something else then valType: 'data_array' instead. For plotly.js, setting those attributes to valType: 'info_array' with freeLength: true would work, but that might break a few things downstream (e.g. the plotly workspace).

Somewhat related: we should also think about correlated arrays mean for trace with 2D coordinate arrays, so that we can eventually extend filter and sort transform to 2D data.

[rreusser]

A quick grep shows three things in plotly.js that depend on 'data_array':

• https://github.com/plotly/plotly.js/blob/master/src/lib/coerce.js#L23-L35
• https://github.com/plotly/plotly.js/blob/master/src/plot_api/plot_schema.js?utf8=%E2%9C%93#L151-L155
• https://github.com/plotly/plotly.js/blob/master/src/plot_api/plot_schema.js?utf8=%E2%9C%93#L368

So seems not tightly coupled within plotly.js. Does changing the field type affect the backend processing? On principle though, I think it'd be nice if data_array meant identically that it has 1-1 correspondence with the trace data.

[etpinard]

PR #2399 added free-length info array declarations (to support layout.grid and layout.grid.subplots).

So perhaps, we could change attributes like ticktext and tickvals to free-length info_array instead of their current data_array val type? That way, we could get rid of this ugly hack.

[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