Support for string targets for isomorphic createPortal

[thysultan]

This is a proposal for the createPortal API to in addition to Nodes support strings for the second argument(container), which could pave a declarative way to achieve out of order server side rendering.

#createPortal(..., container: Node|String, ...)

The server could render a portals children in-place and have the client-side hydration process move it to the right location client-side using document.querySelector if the container is a string.

[gaearon]

See also discussion in #8386: #8386 (comment)

[thysultan]

Have there been discussions on how this might translate to non-DOM environments that might not have the querySelector equivalent?

[gaearon]

Portal implementation itself is agnostic of what you pass as a second argument as long as it's a valid container (i.e. the thing you do the top level render into). For DOM it's a DOM node but for other environments it could be anything that top level render container could be.

[jquense]

Was there a reason the function arg approach wasn't used ? I see it being suggested but not discussed. Is the recommendation to use a canUseDOM guard in render()?

[thysultan]

@gaearon Yes, Node/View objects would translate naturally to other environments, but the idea of the string argument might rely on the environments capabilities to query the view hierarchy with the specified selector; This exists as querySelector in the DOM but equivalent implementations might not exist outside of the DOM.

So that might affect this proposal as far as an isomorphic solution is concerned.

[aweary]

but the idea of the string argument might rely on the environments capabilities to query the view hierarchy with the specified selector; This exists as querySelector in the DOM but equivalent implementations might not exist outside of the DOM.

@thysultan it would be a selector for the DOM renderer, but the string could signify some other target in the other renderers. It would be up to the renderer to determine how to resolve the target based on the string, so there's no inherent coupling to querySelector or the DOM.

[gaearon]

Related: when we do this we might also want to consider renaming it to <React.Portal>.
#11586

[jburghardt]

Are there any new updates on this topic ?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.

[stale]

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!