Q174: React Portals, Modals and Layered UI
What Interviewers Want To Evaluate
This question checks whether you can build layered UI correctly. Interviewers want portals, modal accessibility, focus trapping, focus restoration, inert background, scroll locking, stacking contexts, escape key behavior, nested overlays, event propagation, and server rendering concerns.
Senior answers should treat modals as interaction systems, not decorative layers.
Short Interview Answer
React portals render children into a different DOM container while keeping them in the same React tree. They are useful for modals, tooltips, menus, and overlays that must escape parent overflow or stacking contexts. A correct modal needs focus management, keyboard handling, background inertness, scroll locking, accessible labeling, restore focus on close, and predictable layering. The portal solves placement, not accessibility by itself.
Detailed Interview Answer
A portal renders UI somewhere else in the DOM.
createPortal(
<DialogContent />,
document.getElementById("modal-root"),
);
The component still belongs to the React tree for context and event behavior.
The DOM placement is different.
Why Portals Exist
Overlays often need to escape:
overflow hidden containers
z-index stacking contexts
positioned parents
transformed ancestors
clipped scroll areas
table or grid layout constraints
Rendering near document.body makes layering more predictable.
Portal Does Not Mean Modal
A portal is a rendering mechanism.
A modal is a behavior contract.
Modals require:
role dialog or alertdialog
accessible name
focus moves into dialog
focus stays inside dialog
escape key handling
background is inert
scroll is controlled
focus returns to trigger
close behavior is predictable
The portal handles only where the DOM nodes live.
Focus Management
When a modal opens:
store previously focused element
move focus to the dialog or first useful control
trap tab navigation inside
handle shift-tab
restore focus on close
avoid focusing hidden or disabled elements
Focus behavior is one of the main differences between a real modal and a visual overlay.
Background Inertness
Users should not interact with content behind a modal.
Options include:
native inert attribute
aria-hidden where appropriate
pointer-event blocking
focus guards
modal library support
Be careful with nested portals and screen reader behavior.
Scroll Locking
Opening a modal often locks page scroll.
Scroll locking must handle:
body scrollbar compensation
iOS viewport behavior
nested scroll inside modal
restore previous scroll position
avoid layout shift
multiple overlays open at once
This is a deceptively tricky part of polished UI.
Stacking and Overlay Manager
Complex apps may have menus, popovers, drawers, toasts, and modals.
An overlay manager can define:
z-index layers
escape key priority
outside click behavior
focus stack
body scroll lock count
portal containers
nesting rules
Without this, overlays often fight each other.
Event Propagation
Portal events still propagate through the React tree.
A click inside a portal can trigger React handlers on ancestors even if the DOM nodes are elsewhere.
This is powerful and surprising.
Be explicit with outside click logic and event boundaries.
Tooltips and Menus
Not every overlay is modal.
Tooltips:
should not trap focus
should be described accessibly
should not contain interactive controls
Menus:
need roving focus or active descendant
escape and arrow key behavior
outside click close
typeahead where useful
Each overlay type has its own contract.
Common Mistakes
A common mistake is building a modal that is only a centered div.
Another mistake is forgetting focus restoration.
Another mistake is allowing background controls to be tabbable.
Another mistake is breaking scroll on mobile.
Another mistake is solving z-index one component at a time.
Senior Trade-Offs
Layered UI is cross-cutting. A mature app should centralize overlay primitives instead of rebuilding focus and scroll logic in every feature.
Use proven libraries when accessibility and edge cases matter, especially for dialogs, menus, comboboxes, and popovers.
Debugging Workflow
When an overlay is buggy:
test keyboard open and close
test tab and shift-tab
test escape behavior
test screen reader name
test background inertness
test body scroll lock
inspect stacking contexts
test nested overlays
test mobile viewport behavior
verify focus restoration
Interview Framing
Define portals, separate portal placement from modal behavior, then cover focus, inert background, scroll lock, stacking, event propagation, and accessibility.
Revision Notes
Portals solve DOM placement. Accessible overlays require a full interaction contract.
Key Takeaways
A modal is not complete until keyboard, screen reader, scroll, focus, and layering behavior all work.
Follow-Up Questions
- What does a portal do?
- Does a portal preserve React context?
- Why use portals for modals?
- What makes a modal accessible?
- How should focus move when a modal opens?
- How should focus restore?
- What is background inertness?
- Why is scroll locking hard?
- How do portal events propagate?
- Why use an overlay manager?
How I Would Answer This In A Real Interview
I would say portals render overlay content outside the normal DOM location while preserving React ownership. Then I would explain that a real modal needs focus trapping, background inertness, scroll lock, escape behavior, accessible naming, focus restoration, and consistent overlay layering.