-
Notifications
You must be signed in to change notification settings - Fork 46.8k
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
Make IE 11 not complain about non-crucial style attribute hydration mismatch #13534
Conversation
scripts/rollup/results.json
Outdated
}, | ||
{ | ||
"filename": "react.production.min.js", | ||
"bundleType": "UMD_PROD", | ||
"packageName": "react", | ||
"size": 7217, | ||
"gzip": 3050 | ||
"size": 7289, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please revert changes to this file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gaearon Reverted. I don't know what generated changes to this file, I was just trying to follow https://reactjs.org/docs/how-to-contribute.html...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, it's not currently documented, but you can just always revert it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I already did in this PR. I'll remember for the future. :)
b7c9520
to
5211d2c
Compare
Details of bundled changes.Comparing: 877f8bc...56b4800 react-dom
schedule
Generated by 🚫 dangerJS |
5211d2c
to
6b3e555
Compare
); | ||
}); | ||
|
||
it('should not warn when the style property differs on whitespace only', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how useful this test is; it'd need to be run in IE to make sure there is no regression, other browsers (and jsdom) would pass it even without this PR's changes.
Maybe it's useful as a way of ensuring my changes don't break jsdom?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there anything in jsdom you can monkeypatch for this specific test to reproduce IE behavior? I agree it's kind of useless like this.
0b0e01f
to
4b1a413
Compare
The renaming in #13540 introduced a merge conflict with this PR so I rebased it. Tests still pass. |
expect(element.firstChild.style.textDecoration).toBe('none'); | ||
expect(element.firstChild.style.color).toBe('black'); | ||
|
||
spyOnDevAndProd(console, 'error'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't need this. We check that every test doesn't warn by default. So you can remove it.
// attribute contains invalid CSS declarations but the majority of | ||
// false warnings comes from spacing issues. | ||
// See https://github.com/facebook/react/issues/11807 | ||
return markupNormalized.replace(/\s*([:;])\s*/, '$1').replace(/;$/, ''); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How confident are you in this? What if ;
is part of an image URL or something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's an excellent point. I'm afraid the only certain solution would be to do CSS parsing of the declarations included in the style
attribute but the grammar for that is not that simple:
https://www.w3.org/TR/css-syntax-3/#tokenizing-and-parsing
especially around unquoted URLs so this might be too much.
That said, spaces are not that frequent in URLs, especially around semicolons and colons so this change should have very few false positives as opposed to having false negatives for every style
attribute.
If I understand correctly, this only affects development. How about keeping this logic but only if document.documentMode
is truthy? Regular browsers would work as they are now and developing in IE would be a little less unpleasant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it's fine since we normalize it on both sides. So at most you'll miss some legitimate warnings, but you shouldn't get warnings about valid code. Is that accurate?
Your suggestion to gate this by document.documentMode
sounds good to me too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So at most you'll miss some legitimate warnings, but you shouldn't get warnings about valid code. Is that accurate?
Yes, that's exactly it. And in non-IE browsers you'll still get all the warnings.
A few more points:
|
I'm stripping the last semicolon from the normalized value if one exists and since both the client & the server ones are normalized, this should be fine. I can add a test for that, using the idea from your second point. I can work on that once we resolve the discussion around the |
Your suggestion sounds fine. I didn't realize we normalize both strings. Let's add a test with how I described it, yes. |
4b1a413
to
923c9e7
Compare
I've applied all the discussed changes but I've noticed IE changes the order of CSS declarations, perhaps it sorts them? That makes it more difficult, I need to think what to do... :/ Would splitting on |
I’m worried about perf in DEV. For projects using inline styles sorting every one of them might be pretty slow. Maybe let’s just disable the warning completely for style attribute in IE11? |
…ismatch IE 11 parses & normalizes the style attribute as opposed to other browsers. It adds spaces and sorts the properties in some non-alphabetical order. Handling that would require sorting CSS properties in the client & server versions or applying `expectedStyle` to a temporary DOM node to read its `style` attribute normalized. Since it only affects IE, we're skipping style warnings in that browser completely in favor of doing all that work. Fixes facebook#11807
923c9e7
to
56b4800
Compare
PR updated, IE will not warn for There's a way to make it warn without manual sorting. We could keep a DOM node around, set the computed client-side This shouldn't slow the code down massively as that's what we're already doing on the server-generated nodes - we read the |
element, | ||
); | ||
|
||
delete document.documentMode; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be in try-finally. Even if test fails you want to delete it to avoid breaking other tests
// normalized. Since it only affects IE, we're skipping style warnings | ||
// in that browser completely in favor of doing all that work. | ||
// See https://github.com/facebook/react/issues/11807 | ||
if (!document.documentMode) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extract this to a top level variable like canDiffHydratedStyleForWarning
I'll do follow-up fixes on master. Thanks! |
Glad to help, thanks for landing. :) |
…ismatch (facebook#13534) IE 11 parses & normalizes the style attribute as opposed to other browsers. It adds spaces and sorts the properties in some non-alphabetical order. Handling that would require sorting CSS properties in the client & server versions or applying `expectedStyle` to a temporary DOM node to read its `style` attribute normalized. Since it only affects IE, we're skipping style warnings in that browser completely in favor of doing all that work. Fixes facebook#11807
IE 11 parses & normalizes the style attribute as opposed to other browsers.
The normalization added in this commit normalizes spacing which resolves most
irrelevant style prop warnings, though a warning will still happen if the style
attribute contains invalid CSS declarations.
Fixes #11807