Skip to content

Commit d8555ff

Browse files
gnoffgnoff
committed
[Float][Fizz][Fiber] - Do not hoist elements with itemProp & hydrate more tolerantly in hoist contexts (#26256)
## Do not hoist elements with `itemProp` In HTML `itemprop` signifies a property of an `itemscope` with respect to the Microdata spec (https://html.spec.whatwg.org/multipage/microdata.html#microdata) additionally `itemprop` is valid on any tag and can even make some tags that are otherwise invalid in the `<body>` valid there (`<meta>` for instance). Originally I tried an approach where if you rendered something otherwise hoistable inside an `itemscope` it would not hoist if it had an `itemprop`. This meant that some components with `itemprop` could hoist (if they were not scoped, which is generally invalid microdata implementation). However the problem is things that do hoist, hoist into the head and body and these tags can have an `itemscope`. This creates a ton of ambiguity when trying to hydrate in these hoist scopes because we can't know for certain whether a DOM node we find there was hoisted or not even if it has an `itemprop` attribute. There are other scenarios too that have abiguous semantics like rendering a hoistable with `itemProp` outside of `<html itemScope={true>`. Is it fair to embed that hoistable inside that itemScope even though it was defined outside? To simplify the situation and disambiguate I dropped the `itemscope` portion from the implementation and now any host component that could normally be hoisted will not hoist if it has an `itemProp` prop. In addition to the changes made for `itemProp` this PR also modifies part of the hydration implementation to be more tolerant of tags injected by 3rd parties. This was opportunistically done when we needed to have context information like `inItemScope` but with the most recent implementation that has been removed. I have however left the hydration changes in place as it is a goal to make React handle hydrating the entire Document even when we cannot control whether 3rd parties are going to inject tags that React will not render but are also not hoistables ------- ##### Original Description when we considered tracking itemScope >One recent decision was to make elements using the `itemProp` prop not hoistable if they were inside and itemScope. This better fits with Microdata spec which allows for meta tags and other tag types usually reserved for the `<head>` to be used in the `<body>` when using itemScope. > >To implement this a number of small changes were necessary > >1. HostContext in prod needed to expand beyond just tracking the element namespace for new element creation. It now tracks whether we are in an itemScope. To keep this efficient it is modeled as a bitmask. >2. To disambiguate what is and is not a potential instance in the DOM for hoistables the hydration algo was updated to skip past non-matching instances while attempting to claim the instance rather than ahead of time (getNextHydratable). >3. React will not consider an itemScope on `<html>`, `<head>`, or `<body>` as a valid scope for the hoisting opt-out. This is important as an invariant so we can make assumptions about certain tags in these scopes. This should not be a functional breaking change because if any of these tags have an `itemScope` then it can just be moved into the first node inside the `<body>` > >Since we were already updating the logic for hydration to better support `itemScope` opt-out I also changed the hydration behavior for suspected 3rd party nodes in `<head>` and `<body>`. Now if you are hydrating in either of those contexts hydration will skip past any non-matching nodes until it finds a match. This allows 3rd party scripts and extensions to inject nodes in either context that React does not expect and still avoid a hydration mismatch. > >This new algorithm isn't perfect and it is possible for a mismatch to occur. The most glaring case may be if a 3rd party script prepends a `<div>` into `<body>` and you render a `<div>` in `<body>` in your app. there is nothing to signal to React that this div was 3rd party so it will claim is as the hydrated instance and hydration will almost certainly fail immediately afterwards. > >The expectation is that this is rare and that if falling back to client rendering is transparent to the user then there is not problem here. We will continue to evaluate this and may change the hydration matching algorithm further to match user and developer expectations DiffTrain build for [8a9f82e](8a9f82e)
1 parent 6d81b1f commit d8555ff

22 files changed

+6344
-4549
lines changed

‎compiled/facebook-www/REVISION‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1 +1 @@
1-
3cad3a54eda7b2d1c670c2d414f33d78a4c3f6af
1+
8a9f82ed58c2fa76583a041fa34ad80f5f94a3d1

‎compiled/facebook-www/React-dev.modern.js‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -27,7 +27,7 @@ if (
2727
}
2828
"use strict";
2929

30-
var ReactVersion = "18.3.0-www-modern-2b948334";
30+
var ReactVersion = "18.3.0-www-modern-49cbcd5e";
3131

3232
// ATTENTION
3333
// When adding new symbols to this file,

‎compiled/facebook-www/ReactART-dev.classic.js‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -69,7 +69,7 @@ function _assertThisInitialized(self) {
6969
return self;
7070
}
7171

72-
var ReactVersion = "18.3.0-www-classic-41d9d61e";
72+
var ReactVersion = "18.3.0-www-classic-62fa5a08";
7373

7474
var LegacyRoot = 0;
7575
var ConcurrentRoot = 1;

‎compiled/facebook-www/ReactART-prod.modern.js‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -9448,7 +9448,7 @@ var slice = Array.prototype.slice,
94489448
return null;
94499449
},
94509450
bundleType: 0,
9451-
version: "18.3.0-www-modern-2190fcfa",
9451+
version: "18.3.0-www-modern-20b8c9c5",
94529452
rendererPackageName: "react-art"
94539453
};
94549454
var internals$jscomp$inline_1280 = {
@@ -9479,7 +9479,7 @@ var internals$jscomp$inline_1280 = {
94799479
scheduleRoot: null,
94809480
setRefreshHandler: null,
94819481
getCurrentFiber: null,
9482-
reconcilerVersion: "18.3.0-www-modern-2190fcfa"
9482+
reconcilerVersion: "18.3.0-www-modern-20b8c9c5"
94839483
};
94849484
if ("undefined" !== typeof __REACT_DEVTOOLS_GLOBAL_HOOK__) {
94859485
var hook$jscomp$inline_1281 = __REACT_DEVTOOLS_GLOBAL_HOOK__;

0 commit comments

Comments
 (0)