-
Notifications
You must be signed in to change notification settings - Fork 47.2k
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
Fix #1357. Don't append "px" suffix to CSS string values. #5140
Conversation
👍 lgtm, @spicyj |
We need to do this with a warning for a release to give people the chance to upgrade their code. |
@spicyj Okay. What can I do? Add a |
Yeah. It's a little tricky because ideally you want to also log the containing component and you don't want to log thousands of times so some sort of deduplication is needed (probably based on the component name and CSS property). |
Another option would be |
You can change the API for CSSPropertyOperations to pass in the necessary context if that's helpful. |
@spicyj that would be helpful but how do I avoid creating a memory leak while keeping track of what components I've already warned about? I guess I could just use extendo properties on the DOM nodes but that seems awful and would deduplicate by DOM node, not by component. And I'm not sure I want to add properties to components for that either. |
@pluma We probably wouldn't want to expando on DOM nodes. You could use ReactInstanceMap which is currently implemented as an expando on internal components. Or it would probably be sufficient to warn once per style-key (ie. just create an object and set |
@jimfb Using a single object for all would be pretty straightforward, though. |
@pluma updated the pull request. |
* @return {?string} | ||
*/ | ||
createMarkupForStyles: function(styles) { | ||
createMarkupForStyles: function(styles, context) { |
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.
Could you use the name "component" instead? "Context" often means something else (http://facebook.github.io/react/docs/context.html).
Instead of doing it per component instance, can you deduplicate based on component name? Most of our existing warnings do that already. Sorry that wasn't clear. In most cases you can get |
@pluma Ben is suggesting that you call |
See, for example, ReactElementValidator: react/src/isomorphic/classic/element/ReactElementValidator.js Lines 104 to 106 in 51c0f86
It is true that this makes a small memory leak but it shouldn't be an issue in practice because it grows with the size of your code and doesn't grow as you render more components repeatedly (and is dev mode only). |
Okay, I've adjusted the test so it just keeps record locally instead of polluting the components. |
@pluma updated the pull request. |
} | ||
} | ||
} | ||
return value.trim(); |
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.
We usually warn for a release without a functionality change, and then change functionality the release after. The reason being: if we are emitting warnings, users probably won't/shouldn't be using the "feature" that we are warning for (ie. they need to avoid the feature in order to avoid the warning). For this reason, users won't benefit from the functionality change this release, so we might as well forestall the functionality change until they would actually be able to use it (so as to avoid breaking their apps when they update React versions).
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.
Okay. Should I just revert the original change (i.e. remove the return statement and adjust the tests and docs) then?
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.
Yes, removing the return statement and adjusting the docs sounds good.
@pluma updated the pull request. |
if (__DEV__) { | ||
if (component) { | ||
var owner = component._currentElement._owner; | ||
var componentName = owner ? owner.getName() : component._currentElement.type; |
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 this line correct? It is conflating the owner name with the element type, which feels wrong to me.
I think we actually do want to print both pieces of information (the owner if it exists, and the current element's tag) in the error message. Something like a %s tag (owner: %s) was passed a numeric string value for CSS property
%s(value: %s) which will be treated as a unitless number in a future version of React.
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.
Will do.
@@ -48,7 +51,27 @@ function dangerousStyleValue(name, value) { | |||
} | |||
|
|||
if (typeof value === 'string') { |
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 don't think this check is enough; we should not fire the warning if the string already contains the 'px' at the end. Or actually, it might not always be px (could be 'em' or something). We should only print the warning if the string value can be parsed as an integer.
@pluma I found a couple more things. Sorry for all the churn on this diff, but it is looking good now :). I think we're close! Also, you'll want to squash all the commits into a single commit before we merge. You can use |
@jimfb I've cleaned up the PR, reverted the original commit and adjusted the warning. When this PR is merged, should I create another PR with the original change (and the warning removed) that can later be merged into 0.16? |
@pluma updated the pull request. |
@pluma updated the pull request. |
@pluma Na, you don't need to create a PR for 0.16 yet. The PR would just get old / we would forget about it / there would be merge conflicts / etc. Once we're getting close to the 0.15 release date (you'll know because we will create a 0.15 umbrella issue and start checking things off) then we can start generating PRs for 0.16. I think the only two remaining changes for this PR (in 0.15) are:
|
@jimfb both those points are already addressed by the pre-existing |
Ah, got it! Looks good to me. |
Fix #1357. Don't append "px" suffix to CSS string values.
@pluma Thanks again! |
You're welcome. |
I'm getting a ton of warnings since upgrading to 15.0.1 due to this. We have styles such as https://www.w3.org/TR/CSS2/syndata.html#length-units I'll be happy to submit a PR if this is something wanted. |
Yes, this was merged, just isn’t out yet. See #6458. |
Ah sweet. |
This implements the change discussed in #1357 by simply not appending "px" if the CSS value is already a string.