-
Notifications
You must be signed in to change notification settings - Fork 7.7k
Portal example can cause issues if children access the DOM on componentDidMount #272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi @darrenscerri 😄
I don't think the example in question is that problematic, since the portal is a functional component and so can't have refs. I'd be happy to review a PR that adds a note that mentions the concern you've pointed out though, if you'd like to submit one? 😄 |
Hi @bvaughn :) Agreed, that's a valid point. I guess the idiomatic solution would be something like:
This guarantees that any children's My concern is that users may tend to use the Thoughts? |
Hm, I think that's reasonable. Want to put together a PR? Maybe with an inline comment or two explaining why it does more than may be seemingly necessary at first glance? 😄 |
Sure! Opened a PR here. |
I apologize for resurfacing a long closed issue, but after thoroughly searching the rest of the web this still seems like the most relevant place to post my concern. As @darrenscerri nicely pointed out, if you implement a portal using the example code from the Modal component in React's docs, any child rendered by that portal would not have access to the dom during it's own componentDidMount lifecycle method, which is problematic if a child needs to manipulate or measure the dom at that time. @darrenscerri suggested using state to prevent rendering the children until after the Modal component has had a chance to mount itself, thus allowing the children to initially render into an element that's already been injected into the dom. That solves the problem for the children, but creates a new problem for any ancestors of the Modal component that might need to access a ref to one of those children during their own componentDidMount lifecycle methods, since those children won't get mounted until all of their ancestors have finished mounting. So it appears I'm left with a glaring issue that doesn't seem to have any good resolution. I either implement a portal component like this:
...which will limit what children can be used by the component since those children won't have access to the dom when they're initially mounted. Or I implement a portal component like this:
...which means you won't be able to access a reference to any child of this component during it's initial mount. Or I implement a portal component like this:
This will ensure that both the children and ancestors of this component will have access to what they need during their componentDidMount lifecycle methods, but it creates the possibility of stale nodes should the component ever get removed prior to finishing it's mounting cycle. From what I can tell, there doesn't appear to be a good way to implement a Portal component without having to deal with one of these problems. Am I missing something? |
In the Portal example, the portal container is mounted in the DOM in the
Modal
'scomponentDidMount
methodThis means that when the portal is being mounted, children are initially mounted on a detached node and their
componentDidMount
is called when the component's node is not yet inserted in the DOM. Therefore, any DOM method that requires nodes to be mounted (getting node dimensions, focusing an element, etc.) and props likeautoFocus
will not work.This can be fixed by either moving Modal's
appendChild
method tocomponentWillMount
or using the pattern used by https://github.com/tajo/react-portal/blob/master/src/Portal.js:The text was updated successfully, but these errors were encountered: