Skip to content

Multi-axis Shapes #7666

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
alexshoe wants to merge 10 commits into
base: master
Choose a base branch
from
+405 −139
Draft

Multi-axis Shapes #7666

Changes from 1 commit
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
c8be45f
Extend `xref` and `yref` attributes
alexshoe Dec 2, 2025
a7b3bb2
Add function to help validate number of defining shape vertices
alexshoe Dec 3, 2025
ace820b
Update shape defaults to handle an array of references
alexshoe Dec 4, 2025
a910d42
Modify shape xref/yref coercion logic
alexshoe Dec 5, 2025
4d70fd3
Refactor coercion logic
alexshoe Dec 9, 2025
d3208e9
Implement coordinate value coercion for array refs
alexshoe Dec 17, 2025
e5a71ad
Refactor clip path calculation for multi-axis shapes
alexshoe Dec 19, 2025
4a571aa
Merge branch 'master' into multi-axis-reference-shapes
alexshoe Dec 19, 2025
5f7eedf
Refactor autorange calculation for multi-axis shapes
alexshoe Dec 22, 2025
777cded
update plot-schema diff
alexshoe Dec 27, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Add function to help validate number of defining shape vertices
  • Loading branch information
@alexshoe
alexshoe committed Dec 3, 2025
commit a7b3bb25ad16fcb52ab7fc5703c0728ac3002350
19 changes: 19 additions & 0 deletions src/components/shapes/helpers.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -53,6 +53,25 @@ exports.extractPathCoords = function(path, paramsToUse, isRaw) {
return extractedCoordinates;
};

exports.countDefiningCoords = function(path, isNotPath) {
// non-path shapes always have 2 defining coordinates
if(isNotPath) return 2;
if(!path) return 0;

var segments = path.match(constants.segmentRE);
if(!segments) return 0;

var coordCount = 0;
segments.forEach(function(segment) {
// for each path command, check if there is a drawn coordinate
var segmentType = segment.charAt(0);
var hasDrawnX = constants.paramIsX[segmentType].drawn !== undefined;
var hasDrawnY = constants.paramIsY[segmentType].drawn !== undefined;
if(hasDrawnX || hasDrawnY) coordCount++;
Copy link
Contributor

@emilykl emilykl Dec 4, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm. H and V segments cause an odd usability issue I hadn't considered: if a path contains H and V segments then the expected lengths of xref and yref may be different, and the corresponding list items will be "out of sync" with respect to which path segments they correspond to (i.e. it will not always be the case that xref[n] and yref[n] refer to the same path segment).

For example here is a rectangular path: M0,0H10V5H0Z (see visualization)

There are four segments (not counting Z), but only 3 x-values and 2 y-values are needed to define the shape. So you would have:

{
    "path": "M0,0H10V5H0Z",
    "xref": ["x", "x2", "x"],
    "yref": ["y", "y2"],
}

which is a bit odd, and sort a high cognitive load for the user to figure out the right xref and yref lists.

That said, it seems probably better than the other alternative that comes to mind, which would be to force the user to add an xref and a yref for every single segment, even if it will be ignored for some segments.

});
return coordCount;
};

exports.getDataToPixel = function(gd, axis, shift, isVertical, refType) {
var gs = gd._fullLayout._size;
var dataToPixel;
Expand Down