-
-
Notifications
You must be signed in to change notification settings - Fork 8.9k
fix(runtime-dom): TransitionGroup
should compare position base on transform-origin
#13991
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.
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
Conversation
…transform-origin`
WalkthroughReworks position tracking in TransitionGroup by introducing a Position type and a calculatePosition helper that factors in transform and transformOrigin. Replaces direct DOMRect usage and getBoundingClientRect calls with calculated positions, updating WeakMaps (positionMap, newPositionMap) and registration/recording routines accordingly. No exported/public declarations changed. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor User
participant TransitionGroup
participant ChildEl as Child Element
participant Calc as calculatePosition
participant PosMap as positionMap
participant NewPosMap as newPositionMap
User->>TransitionGroup: mount/update
loop initial registration
TransitionGroup->>Calc: calculatePosition(ChildEl)
Calc-->>TransitionGroup: Position { left, top }
TransitionGroup->>PosMap: set(ChildEl, Position)
end
Note over TransitionGroup: On move/update
TransitionGroup->>Calc: calculatePosition(ChildEl)
Calc-->>TransitionGroup: Position { left, top }
TransitionGroup->>NewPosMap: set(ChildEl, Position)
TransitionGroup->>TransitionGroup: compute deltas and apply moves
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested labels
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
packages/runtime-dom/src/components/TransitionGroup.ts
(3 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
packages/runtime-dom/src/components/TransitionGroup.ts (1)
packages/compiler-core/src/ast.ts (1)
Position
(83-87)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Redirect rules
- GitHub Check: Header rules
- GitHub Check: Pages changed
const [ox, oy] = style.transformOrigin.split(' ').map(v => parseFloat(v)) | ||
const point = new DOMPoint(ox, oy) | ||
const transformed = point.matrixTransform(matrix) | ||
|
||
return { left: transformed.x + rect.left, top: transformed.y + rect.top } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Transform origin parsing breaks for percentages/keywords
parseFloat
on style.transformOrigin
treats 50%
as 50
(interpreted as 50 px) and returns NaN
for keywords such as center
, left
, etc. That makes calculatePosition
report incorrect or NaN
offsets when authors use the default 50% 50%
origin or keyword-based origins, so moves are computed from the wrong point and transitions visibly jump. Please resolve the transform-origin string into actual pixel offsets (handle %
, the keyword set, and fall back to the axis size) before feeding it to the DOMMatrix.
🤖 Prompt for AI Agents
In packages/runtime-dom/src/components/TransitionGroup.ts around lines 198-202,
the transform-origin parsing currently uses parseFloat which treats "50%" as 50
and returns NaN for keywords; update calculatePosition to resolve
transformOrigin tokens into pixel offsets before creating the DOMPoint: split
the transformOrigin into x/y (support single-value shorthand by using '50%' for
missing axis), for each token if it endsWith('%') compute
(parseFloat(token)/100) * axisSize (rect.width for x, rect.height for y), else
if it is a keyword map 'left'->0%,'center'->50%,'right'->100% and similarly
'top'->0%,'center'->50%,'bottom'->100%, else parseFloat and treat as pixels,
then use those computed ox/oy pixel values to construct the DOMPoint and
continue with matrixTransform and return offsets.
@vue/compiler-core
@vue/compiler-dom
@vue/compiler-sfc
@vue/compiler-ssr
@vue/reactivity
@vue/runtime-core
@vue/runtime-dom
@vue/server-renderer
@vue/shared
vue
@vue/compat
commit: |
Size ReportBundles
Usages
|
Thanks for this PR, but this PR is a duplicate of #6108. |
close #13990
Summary by CodeRabbit
Bug Fixes
Refactor