* Update Portals Documentation
Correct some grammar to be more explicit and clear. Update example CodePen to better match code found in documentation. Update code example styles to match other code examples (ie. 'State and Lifecycle', 'Handling Events').
* Clean up comment to be accurate to example
There was a small comment overlooked when reviewing the documentation. This fixes it to be accurate to the example as well as grammatically correct.
* Update portals.md
* More fixes
@ -44,47 +44,71 @@ A typical use case for portals is when a parent component has an `overflow: hidd
> Note:
> Note:
>
>
> For most uses portals, you'll need to make sure to follow the proper accessibility guidelines.
> It is important to remember, when working with portals, you'll need to make sure to follow the proper accessibility guidelines.
[Try out an example on CodePen.](https://codepen.io/acdlite/pen/JrKgmz)
[Try out an example on CodePen.](https://codepen.io/acdlite/pen/JrKgmz)
## Portals and event bubbling
## Portals and event bubbling
A nice feature of portals is that, even though the DOM node 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.
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*:
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
<html>
<body>
<divid="app-root"></div>
<divid="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.
// This will fire when the button in Child is clicked, updating Parent's state,
// even though Child is not a direct descendant in the DOM.
this.setState(prevState => ({
clicks: prevState.clicks + 1
}));
}
render() {
render() {
return (
return (
<divonClick={this.onClick}>
<divonClick={this.onClick}>
<p>Number of clicks: {this.state.clicks}</p>
<p>Number of clicks: {this.state.clicks}</p>
<p>Open up the browser DevTools to observe that the button is not a child the div with onClick handler.</p>
<p>Open up the browser DevTools to observe that the button is not a child the div with onClick handler.</p>
{ReactDOM.createPortal(<Child/>, modalContainer)}
{ReactDOM.createPortal(<Child/>, modalRoot)}
</div>
</div>
);
);
}
}
}
}
function Child() {
function Child() {
return <button>Click</button>;
// The click event on this button will bubble up to parent,
// because there is no 'onClick' attribute defined
return (
<divclassName="modal">
<button>Click</button>
</div>
);
}
}
ReactDOM.render(<Parent/>, appContainer);
ReactDOM.render(<Parent/>, appRoot);
```
```
[Try this example on CodePen](https://codepen.io/acdlite/pen/MEJEVV).
[Try this example on CodePen](https://codepen.io/gaearon/pen/jGBWpE).
The advantage of treating portal event bubbling this way is that it makes it easier to build abstractions. For example, if you render a `<Modal />` component, the parent can capture its events regardless of whether it's implemented using portals.
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.