fix(drawer): Fixed the problem that the table component in the drawer component cannot be displayed normally in full screen #3782
Conversation
WalkthroughTwo drawer component templates receive identical style binding updates. A conditional Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
packages/vue/src/drawer/src/mobile-first.vue(1 hunks)packages/vue/src/drawer/src/pc.vue(1 hunks)
⏰ 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). (1)
- GitHub Check: PR E2E Test (pnpm test:e2e3)
🔇 Additional comments (1)
packages/vue/src/drawer/src/mobile-first.vue (1)
35-36: Verify that drawer animations work correctly with the new inline transform style.The inline
transform: 'none'style (line 35) will override the Tailwind transform classes when the drawer is visible. Existing tests only verify final CSS properties and dimensions—they don't test animation smoothness or transition timing. The placement test checks that CSS properties are set (left: 0px, etc.), and the dragable test checks that dimensions change, but neither verifies that the drawer slides smoothly when opening or closing, or that the transition animation works correctly with the inline style override.Manually verify:
- Drawer slides smoothly when opened/closed in all placements (top/bottom/left/right)
- Animation timing remains consistent with the
duration-200class- Drag functionality works without animation glitches when
dragableis enabled
| zIndex, | ||
| transform: state.visible ? 'none' : null |
There was a problem hiding this comment.
🧩 Analysis chain
Verify Vue transition compatibility with the inline transform style.
The transform: 'none' inline style will override any CSS transforms defined in the Vue transition classes (e.g., .drawer-slide-left-enter-active). This is necessary to remove the containing block and fix the fullscreen table issue, but it may interfere with Vue's transition system.
Please verify that:
- The Vue transition classes for
drawer-slide-${placement}still work correctly with the inline transform - Enter and leave transitions animate smoothly without jumping
- The transition doesn't conflict during the enter/leave phases when Vue is adding/removing classes
Additionally, consider whether the transition CSS should be updated to avoid using transform if the inline style will always override it when visible.
🏁 Script executed:
#!/bin/bash
# Search for the drawer transition class definitions
rg -n --type=less --type=css --type=scss -A5 'drawer-slide|drawer-fade'
# Check if there are styles that use transform for drawer animations
ast-grep --pattern $'drawer {
$$$
transform: $_;
$$$
}'Length of output: 28
🏁 Script executed:
#!/bin/bash
# Search for drawer transition CSS without strict file type
rg -n 'drawer-slide|drawer-fade' --type=css --type=less -A5
# If above finds nothing, search all files
if [ $? -ne 0 ]; then
echo "=== Searching in all files for drawer-slide ==="
rg -n 'drawer-slide|drawer-fade' -A5 --max-count=20
fi
# Look for Vue component style blocks or animation/keyframe definitions
echo "=== Searching for animation/keyframe definitions ==="
rg -n 'animation:|keyframes|@keyframes' --type=css --type=less | grep -i drawer
# Check if there are dedicated style files in drawer directory
echo "=== Files in drawer directory ==="
fd -e css -e less -e scss -e vue packages/vue/src/drawer 2>/dev/null | head -20Length of output: 11155
🏁 Script executed:
#!/bin/bash
# Get complete keyframe definitions to see what properties they animate
echo "=== Complete slideLeft keyframe ==="
rg -n 'slideLeft' -A15 packages/theme/src/drawer/index.less | head -40
echo "=== Complete slideTop keyframe ==="
rg -n '@keyframes slideTop' -A10 packages/theme/src/drawer/index.less
echo "=== Complete slideRight keyframe ==="
rg -n '@keyframes slideRight' -A10 packages/theme/src/drawer/index.lessLength of output: 1581
Critical Animation Breaking Issue
The inline transform: 'none' when state.visible is true will break the drawer enter animations. All slide keyframes (slideLeft, slideRight, slideTop, slideBottom) use transform: translateX() or transform: translateY() to animate position. When the drawer opens, the inline style will override these animation values, preventing the drawer from sliding in.
The drawer will appear instantly without animation on enter, and animations will only work on leave (when transform is null).
Required: Replace the inline transform style with a CSS class approach or use CSS animation-fill-mode to preserve animation behavior while maintaining the containing block fix.
🤖 Prompt for AI Agents
In packages/vue/src/drawer/src/pc.vue around lines 35-36, the inline style
setting transform: state.visible ? 'none' : null breaks enter animations by
overriding keyframed translate transforms; remove the inline transform and
instead toggle a CSS class (e.g., .contain-fix) when visible that applies the
containing/z-index fix without setting transform, or alternatively ensure the
animation uses animation-fill-mode (and remove the inline transform) so keyframe
translateX/translateY can run on enter; update the template to add/remove the
class and add the corresponding CSS rule to achieve the containing behavior
without an inline transform override.
fix(drawer): 修复drawer组件中表格组件全屏无法正常展示问题
PR
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?
Other information
Summary by CodeRabbit