mirror of
https://github.com/facebook/react.git
synced 2025-11-01 09:12:30 +00:00
Sebastian Markbåge
e5dd82a79d
The problem with setting both `children` or `dangerouslySetInnerHTML` and also using a ref on a DOM node to either manually append children or using it as a Container for `createRoot` or `createPortal` is that it's ambiguous which children should win. Ideally you use one of the four options to control children. Meaning that ideally you always use a leaf container for refs like this. Unfortunately it's very common to use a React owned thing with children as a Container of a Portal. For example `document.body` can have both regular React children and be used as a Portal container. This isn't really fully supported and has some undefined behavior like relative order isn't guaranteed but still very common. It is extra bad if the children are a `string`/`number` or if `dangerouslySetInnerHTML` is set. Because then when ever that reactively updates it'll clear out any manually added DOM nodes. When this happens isn't guaranteed. It's always happening as far as the reactivity is concerned. See https://github.com/facebook/react/issues/31600 Therefore, we should warn for this specific pattern. This still allows non-text children as a compromise even though that behavior is also somewhat undefined.