Plotly.react sequence and transforms

[nicolaskruchten]

The sequence of calls to Plotly.react laid out in this pen https://codepen.io/nicolaskruchten/pen/pLamVv?editors=1010 causes display problems in the last step. The buttons allow you to step through the sequence using a mix of newPlot and react to taste.

[nicolaskruchten]

Related to #2470?

[alexcjohnson]

Two tests to add, probably to transform_groupby_test, when fixing this:

• relinkPrivateKeys React finance precursor #2525 (comment)
• Plotly.react diffing on fullInput React finance precursor #2525 (comment)

[alexcjohnson]

A new rule I'm considering implementing & enforcing, to help ensure transforms work correctly with all trace types:

• Every trace must define _length, and MUST do it during supplyDefaults so it's available before any transforms operate.
• This is (at least for now) only appropriate for traces that have 1D data - so it applies for example to heatmaps if you provide triplet data (x/y/z are all 1D) but not if z is 2D.
• When it does not apply, set _length = null, and all transforms that operate on the assumption of 1D data (which is currently all of them) will be automatically disabled.

@etpinard thoughts?

[etpinard]

I like it. It sounds like a nice way to 🔒 the current behavior. If ever we start supporting transforms on 2D arrays, we can reassess.

[alexcjohnson]

If ever we start supporting transforms on 2D arrays, we can reassess.

Yes - just looking at table traces... it would be sweet to be able to filter/sort/aggregate a table, but this has (at least) two problems right now:

• cells.values is a 2D array... our transforms wouldn't know what to do with this, and generally you'd want the transform target to be one column of that, but we don't have a mechanism to pick out a column.
• header.values is also a 2D array, so it'll show up in _arrayAttrs and if we try to continue using automatic array collection we'll have to find a way to exclude headers.

Anyway trying to generalize this to other 2D trace types seems tough, given all the different combinations of 1D & 2D data available within a single trace type, with some of the 1D arrays matching columns of the 2D, some matching rows, some allowing 1D or 2D, etc etc... So either each transform would have to be specifically extended for each 2D trace type it wants to support or we'd need a way to describe (in the schema?) which dimensions of which attributes relate to each other.

So with _length = null we can disable this explicitly, then re-enable it type-by-type as we figure it out.

[etpinard]

So with _length = null we can disable this explicitly, then re-enable it type-by-type as we figure it out.

Great 👌