fix(editor): Preserve closed-path Z command when moving a path (#1093) - #1100
Merged
Conversation
remapElement's native getPathData() branch matched close-path segments against a pathMap that only listed lowercase 'z', but paths serialize the close command as uppercase 'Z'. The indexOf lookup returned -1, leaving a hole in the segment array that later crashed with "Cannot destructure property 'type' of undefined" when the path was moved, aborting the update and making the shape snap back in place (Firefox only, since Chrome falls back to the legacy pathSegList API). Also fixed newPathData missing a case for the close-path segment, which would have silently dropped it once the crash was fixed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Reviewer's GuideFixes remapElement’s handling of closed SVG paths so that uppercase 'Z' close commands are correctly mapped and preserved when using native getPathData/setPathData, and adds regression tests to cover both attribute-based and native-path-data flows. File-Level Changes
Assessment against linked issues
Possibly linked issues
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Closed
There was a problem hiding this comment.
Hey - I've left some high level feedback:
- In
remapElement, theswitch (type)branch uses the magic numbercase 1to represent closepath; consider deriving this frompathMap.indexOf('z')or using a named constant to avoid coupling the behavior to the currentpathMapordering. - The
parsedPathDataobject in thegetPathDatatest stub is reused across calls and may be mutated byremapElement; consider returning a fresh clone fromgetPathData()to keep the test isolated from internal mutations.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- In `remapElement`, the `switch (type)` branch uses the magic number `case 1` to represent closepath; consider deriving this from `pathMap.indexOf('z')` or using a named constant to avoid coupling the behavior to the current `pathMap` ordering.
- The `parsedPathData` object in the `getPathData` test stub is reused across calls and may be mutated by `remapElement`; consider returning a fresh clone from `getPathData()` to keep the test isolated from internal mutations.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Replace the magic number 1 with a CLOSEPATH_TYPE constant derived from
pathMap.indexOf('z') so the switch branch doesn't silently break if
pathMap's ordering ever changes. Also make the getPathData test stub
return a fresh clone on each call so remapElement can't leak mutations
back into the fixture data.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Cannot destructure property 'type' of undefined.remapElement()'s nativegetPathData()branch inpackages/svgcanvas/core/coords.jsmaps each path segment's letter (M,L,Z, ...) to a numeric type viapathMap.indexOf(t).pathMaponly lists the lowercase'z'for the close-path command, but paths serialize the close command as uppercase'Z'. The lookup returned-1, leaving a hole in the segment array; a later loop destructuredtypeoff that hole and threw, aborting the move before the new geometry was committed. This only reproduces in browsers with nativegetPathData/setPathDatasupport (e.g. Firefox) — Chrome falls back to the legacypathSegListAPI, which uses numeric constants instead of letters and isn't affected, matching what's reported in the issue thread.newPathDatabuilder had no case for the close-path segment type, so even after the crash is fixed, callingsetPathData()would silently drop theZand reopen the shape.Test plan
tests/unit/coords.test.jsthat stubsgetPathData/setPathDataon a closed path (simulating Firefox) and verifies the move no longer throws and the closed shape (and itsZcommand) is preserved.npx vitest run tests/unit— 569 tests pass.npx standard— no lint errors on changed files.🤖 Generated with Claude Code
Summary by Sourcery
Preserve closed SVG paths when remapping elements so translated shapes remain closed across browsers.
Bug Fixes:
Tests: