Multi-axis Shapes

[alexshoe]

Description:

Extends xref and yref to accept arrays, allowing shapes to span multiple subplots with each vertex anchored to a different axis. See #7151 for more information.

Example:

shapes: [{  
  type: 'rect',  
  x0: 0, 
  x1: 1, 
  y0: 0, 
  y1: 1,  
  xref: ['x', 'x2'],  // x0 uses 'x', x1 uses 'x2'  
  yref: ['y', 'y2']   // y0 uses 'y', y1 uses 'y2'
}]

Progress:

• Step 1: Attributes & validation
  • Extend xref and yref to allow array values
  • Add helper function to check number of defining coordinates of a shape
  • Update value validation to work with array values
• Step 2: Refactor coordinate conversion
• Step 3: Update shape rendering
• Step 4: Addressing editable shapes
• Step 5: Tests + documentation

[emilykl]

@alexshoe Could you add a label to each of these shapes to make sure everything works as expected?

[emilykl]

@alexshoe This is looking really good. 🎉

I left some minor comments on the implementation (mostly style and readability) and also noticed some issues with the Jasmine tests. Could you do a pass through all the Jasmine tests and make sure they make sense, are testing the right things, etc.

I also realized there's a pretty good chance that shape.label.texttemplate won't play nice with this feature at all. I would expect variables x0, x1, y0, y1 to work as expected, but the remaining ones simply don't make any sense when the endpoints are associated with different axes. Can you test out what happens? There should be a decent error case (ignore the variable, perhaps?) rather than a catastrophic failure or showing the wrong information.

[alexshoe]

@emilykl Thanks for the comments! I tested texttemplate with multi-axis shapes and it doesn't cause an error but the derived values (e.g. width, height, slope, et.c) don't make any sense as you predicted. Raw values (x0, x1, y0, y1) work fine but something like width would be meaningless since we're mixing coordinates from different axes. Should I document this limitation somewhere or maybe throw an error?

Meanwhile, I also modified the code to display labels for non-path shapes since it previously didn't work well with multi-axis references. Also added labels to the image test to confirm that it works.

[emilykl]

@alexshoe Thanks to @camdecoster 's work in #7577 , we now have the shape.texttemplatefallback attribute, which is already used in cases where the given variable name is invalid. So I propose we use texttemplatefallback for the derived variables for multi-axis shapes. See the text_on_shapes_texttemplate mock for an example of how this works in practice (%{length} on the rectangle in the upper-right subplot is replaced with - because length is an invalid variable for rectangles).

Good news that raw values work as expected!

[emilykl]

Should probably use .toBeCloseTo() here as well

[alexshoe]

It seems the expected values all vary a bit, probably different amounts of padding added by autorange.
Should I modify the precision of toBeCloseTo or should I just stick with toBeLessThan/toBeGreaterThan?

[emilykl]

@alexshoe How much do the values vary between test runs? That's the important question.

I wouldn't necessarily expect the values to be exact round numbers but I would expect them to be pretty much the same from run to run.