* [18] ReactDOM reference to createRoot/hydrateRoot (#4340) * [18] ReactDOM reference to createRoot/hydrateRoot * Update note about render and hydrate * Match the warning text * s/Render/render * [18] Update ReactDOMClient docs (#4468) * [18] Update ReactDOMClient docs * Remove ReactDOMClient where it's obvious * Update browser message * Update browser message note * Update based on feedback * Add react-dom/client docs * [18] Upgrade homepage examples (#4469) * [18] Switch code samples to createRoot (#4470) * [18] Switch code samples to createRoot * Feedback fixes * Feedback updates * [18] Use hydrateRoot and root.unmount. (#4473) * [18] Add docs for flushSync (#4474) * [18] Add flushSync to ReactDOM docs * Seb feedback * More Seb feedback * [18] Bump version to 18 (#4478) * [18] Update browser requirements (#4476) * [18] Update browser requirements * Update based on feedback * [18] Add stubs for new API references (#4477) * [18] Add stubs for new API references * Change order/grouping * [18] Redirect outdated Concurrent Mode docs (#4481) * [18] Redirect outdated Concurrent Mode docs * Use Vercel redirects instead * [18] Update versions page (#4482) * [18] Update version page * Fix prettier * [18] Update React.lazy docs (#4483) * [18] Add docs for useSyncExternalStore (#4487) * [18] Add docs for useSyncExternalStore * rm "optional" * [18] Add docs for useInsertionEffect (#4486) * [18] Add docs for useId (#4488) * [18] Add docs for useId * Update based on feedback * Add Strict Effects to Strict Mode (#4362) * Add Strict Effects to Strict Mode * Update with new thinking * [18] Update docs for useEffect timing (#4498) * [18] Add docs for useDeferredValue (#4497) * [18] Update suspense docs for unexpected fallbacks (#4500) * [18] Update suspense docs for unexpected fallbacks * Add inline code block * Feedback fixes * [18] Updated Suspense doc with behavior during SSR and Hydration (#4484) * update wording * wording * update events * Update content/docs/reference-react.md Co-authored-by: Sebastian Silbermann <silbermann.sebastian@gmail.com> * add link to selective hydration * remove some of the implementation details Co-authored-by: Sebastian Silbermann <silbermann.sebastian@gmail.com> * [18] renderToPipeableStream doc (#4485) * new streaming ssr api * add readable stream * code snippets * Rename strict effects / unsafe effects to use the reusable state terminology (#4505) * Add draft of 18 release post * Add links to speaker Twitter profiles * [18] Update upgrade guide * Fix typo in blog title * [18] Blog - add note for react native * [18] Add changelog info to blog posts * Edit Suspense for data fetching section * Update date * [18] Add links * Consistent title case * Update link to merged RFC * [18] Update APIs and links * [18] Add start/useTransition docs (#4479) * [18] Add start/useTransition docs * Updates based on feedback * [18] Generate heading IDs * Add note about Strict Mode * Just frameworks * Reorder, fix content * Typos * Clarify Suspense frameworks section * Revert lost changes that happened when I undo-ed in my editor Co-authored-by: salazarm <salazarm@users.noreply.github.com> Co-authored-by: Sebastian Silbermann <silbermann.sebastian@gmail.com> Co-authored-by: Sebastian Markbåge <sebastian@calyptus.eu> Co-authored-by: Andrew Clark <git@andrewclark.io> Co-authored-by: dan <dan.abramov@gmail.com>
4.9 KiB
id, title, permalink
| id | title | permalink |
|---|---|---|
| portals | Portals | docs/portals.html |
Portals provide a first-class way to render children into a DOM node that exists outside the DOM hierarchy of the parent component.
ReactDOM.createPortal(child, container)
The first argument (child) is any renderable React child, such as an element, string, or fragment. The second argument (container) is a DOM element.
Usage
Normally, when you return an element from a component's render method, it's mounted into the DOM as a child of the nearest parent node:
render() {
// React mounts a new div and renders the children into it
return (
<div>
{this.props.children}
</div>
);
}
However, sometimes it's useful to insert a child into a different location in the DOM:
render() {
// React does *not* create a new div. It renders the children into `domNode`.
// `domNode` is any valid DOM node, regardless of its location in the DOM.
return ReactDOM.createPortal(
this.props.children,
domNode
);
}
A typical use case for portals is when a parent component has an overflow: hidden or z-index style, but you need the child to visually "break out" of its container. For example, dialogs, hovercards, and tooltips.
Note:
When working with portals, remember that managing keyboard focus becomes very important.
For modal dialogs, ensure that everyone can interact with them by following the WAI-ARIA Modal Authoring Practices.
Event Bubbling Through Portals
Even though a portal can be anywhere in the DOM tree, it behaves like a normal React child in every other way. Features like context work exactly the same regardless of whether the child is a portal, as the portal still exists in the React tree regardless of position in the DOM tree.
This includes event bubbling. An event fired from inside a portal will propagate to ancestors in the containing React tree, even if those elements are not ancestors in the DOM tree. Assuming the following HTML structure:
<html>
<body>
<div id="app-root"></div>
<div id="modal-root"></div>
</body>
</html>
A Parent component in #app-root would be able to catch an uncaught, bubbling event from the sibling node #modal-root.
// These two containers are siblings in the DOM
const appRoot = document.getElementById('app-root');
const modalRoot = document.getElementById('modal-root');
class Modal extends React.Component {
constructor(props) {
super(props);
this.el = document.createElement('div');
}
componentDidMount() {
// The portal element is inserted in the DOM tree after
// the Modal's children are mounted, meaning that children
// will be mounted on a detached DOM node. If a child
// component requires to be attached to the DOM tree
// immediately when mounted, for example to measure a
// DOM node, or uses 'autoFocus' in a descendant, add
// state to Modal and only render the children when Modal
// is inserted in the DOM tree.
modalRoot.appendChild(this.el);
}
componentWillUnmount() {
modalRoot.removeChild(this.el);
}
render() {
return ReactDOM.createPortal(
this.props.children,
this.el
);
}
}
class Parent extends React.Component {
constructor(props) {
super(props);
this.state = {clicks: 0};
this.handleClick = this.handleClick.bind(this);
}
handleClick() {
// This will fire when the button in Child is clicked,
// updating Parent's state, even though button
// is not direct descendant in the DOM.
this.setState(state => ({
clicks: state.clicks + 1
}));
}
render() {
return (
<div onClick={this.handleClick}>
<p>Number of clicks: {this.state.clicks}</p>
<p>
Open up the browser DevTools
to observe that the button
is not a child of the div
with the onClick handler.
</p>
<Modal>
<Child />
</Modal>
</div>
);
}
}
function Child() {
// The click event on this button will bubble up to parent,
// because there is no 'onClick' attribute defined
return (
<div className="modal">
<button>Click</button>
</div>
);
}
const root = ReactDOM.createRoot(appRoot);
root.render(<Parent />);
Catching an event bubbling up from a portal in a parent component allows the development of more flexible abstractions that are not inherently reliant on portals. For example, if you render a <Modal /> component, the parent can capture its events regardless of whether it's implemented using portals.