Multiple roots don't have any particular defined order with regard to which one wins etc when it comes to scheduling since it's not encoded. It also doesn't encode things like "offscreen" mode if its parent hides or get virtualized. What happens if something suspends (the assumption is that we'll have automatically suspending things like auto-lazy, so anything could suspend), what part of the UI is it a necessary part of? And ofc, Context.
The idea is that any component author throughout the ecosystem should be able to rely on these rather than having to keep in mind whether they're in a special context or not.
The other aspect is that ideally you should be able to build SPAs where basically the whole shell is swappable client side or has bottom/top bars that conceptually outside the app. Therefore even global UIs should ideally have some kind of context for which shell they're conceptually stacked into. We also have plans for a "backgrounded" mode where something can keep living inside the tree while the outside is more or less frozen or deprioritized. Portals can then stick out of the backgrounded mode.
That's why Portals are recommended as a way to preserve some sense of the conceptual context where something belongs so all those things can happen automatically.
In the ToastManager case, that seems like a case where you actually don't want to carry over the context of where you're executing. E.g. unlike a tooltip you don't need to hide the toast when the parent hides. That's probably a good candidate for just having a component that lets you place the rendering of the Toasts somewhere in the tree. Like having a singleton component register itself with the ToastManager and listen to things it should render. No Portals. Maybe that could be made a requirement for 18, and otherwise it still works but you get the warning.
The LiveAnnouncer is interesting because it doesn't accept arbitrary React children so there's no confusion other than internals. Tbh, in this case I'd just not use React at all and just insert manual DOM nodes. It's just simulating a text-based API anyway.
The useDrag example is interesting since it's an example where you can't have any typical expectations of what you can do in a React component because it's synchronous, frozen and non-interactive. I think you probably can have the expectation that you inherit Contexts (e.g. theme or other things) though when rendering an icon or whatever. It would be nice if it was a Portal for that reason.
In this case it would be nice if you could have a Portal in a Hook. However, that's usually not necessarily the best, because placing it in the tree gives meaning to where it is in the tree for event bubbling, and where it suspends. E.g. it gives you an option to wrap it in a Suspense boundary and give it semantics with SuspenseList.
In this special case, since it has no semantics related to the tree other than the Context, it would be nice if we had a usePortal API.
@devongovett Note that if the user uses some kind of framework that registers itself in an useEffect or something inside the Preview component. An easy mistake to make if you use pretty much any framework. It'll currently leak because you don't unmount the root. The new root API will likely start warning for that case. If you have multiple roots and the root gets dropped without ever unmounting (using weakrefs). I'd probably make sense to unmount it before removeChild is called.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4