fix(react-drag-drop): support dynamic root element IDs in DragDropCon…#12240
fix(react-drag-drop): support dynamic root element IDs in DragDropCon…#12240arpanroy41 wants to merge 3 commits intopatternfly:mainfrom
Conversation
…tainer Fixes patternfly#12217 - Replace hardcoded document.getElementById('root') with dynamic root element lookup - Add getRootElement() helper that tries common root IDs: 'root', 'app', 'main', '__next' - Fallback to document.body if no common root element is found - Enables usage in applications with non-standard root element IDs (e.g., id="app") This fix allows OCP 4.22 and other applications to use @patternfly/react-drag-drop regardless of their React root element configuration.
WalkthroughReplaced the hardcoded portal target lookup with a dynamic root element resolution that searches common root IDs ('root', 'app', 'main', '__next') and falls back to Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
|
Preview: https://pf-react-pr-12240.surge.sh A11y report: https://pf-react-pr-12240-a11y.surge.sh |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@packages/react-drag-drop/src/components/DragDrop/DragDropContainer.tsx`:
- Around line 293-304: Replace the fragile getRootElement() guessing logic with
a deterministic optional portalContainer prop: add portalContainer?: HTMLElement
to the component props/interface for DragDropContainer, update the
DragDropContainer function signature to accept this prop, remove or stop calling
getRootElement(), and use (portalContainer ?? document.body) wherever
getRootElement() was used to determine the portal target; this mirrors
PatternFly's appendTo behavior and keeps document.body as the default fallback.
🧹 Nitpick comments (1)
packages/react-drag-drop/src/components/DragDrop/DragDropContainer.tsx (1)
317-317:getRootElement()is invoked on every render, performing DOM lookups each time.While
getElementByIdis fast and thecanUseDOMguard correctly prevents SSR issues, the deeper problem is that the portal target discovered here may be a non-root element (see the comment above on'main'). Once the approach is changed to a prop-based solution, this line becomes clean and efficient.
packages/react-drag-drop/src/components/DragDrop/DragDropContainer.tsx
Outdated
Show resolved
Hide resolved
packages/react-drag-drop/src/components/DragDrop/DragDropContainer.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@packages/react-drag-drop/src/components/DragDrop/DragDropContainer.tsx`:
- Around line 294-305: The useMemo that computes rootElement currently accesses
document.getElementById and will crash during SSR; modify the rootElement
computation (the useMemo block that defines rootElement) to first check the
existing canUseDOM guard and return null (or document.body only when canUseDOM
is true) when DOM is unavailable so no document.* calls run on the server; keep
the later createPortal usage that already checks canUseDOM intact so the
component renders safely during SSR.
…rning null for root element
|
@nicolethoen Can you please rerun the |
Fixes #12217
This fix allows OCP 4.22 and other applications to use @patternfly/react-drag-drop regardless of their React root element configuration.
Summary by CodeRabbit