Fix #1357. Don't append "px" suffix to CSS string values. #5140

pluma · 2015-10-12T15:29:30Z

This implements the change discussed in #1357 by simply not appending "px" if the CSS value is already a string.

jimfb · 2015-10-12T17:02:44Z

👍 lgtm, @spicyj

sophiebits · 2015-10-12T17:07:44Z

We need to do this with a warning for a release to give people the chance to upgrade their code.

pluma · 2015-10-12T17:55:14Z

@spicyj Okay. What can I do? Add a warning(false, "message goes here") to it?

sophiebits · 2015-10-12T17:58:39Z

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).

pluma · 2015-10-12T18:28:48Z

CSSPropertyOperations.setValueForStyles would be an option -- it gets called in most of the right places and has access to the DOM node and the styles. Only problem would be deduplication. And I'm not sure whether it is called on the initial render (probably not?).

Another option would be ReactDOMComponent._createOpenTagMarkupAndPutListeners but it would require looping over all the property names again and checking for numeric strings (which seems redundant).

sophiebits · 2015-10-12T18:32:20Z

You can change the API for CSSPropertyOperations to pass in the necessary context if that's helpful.

pluma · 2015-10-12T18:48:02Z

@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.

jimfb · 2015-10-12T20:55:55Z

@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 object[styleKey] = true if you've already warned for that style). That would mean that fixing the warning in one component could result in a similar warning starting to be emitted from another component that has the same bug, but that is probably acceptable (@spicyj to confirm).

pluma · 2015-10-13T13:33:56Z

@jimfb ReactInstanceMap seems to be just a way to get an internal instance for a component, the internal instance itself is sealed (doesn't take arbitrary properties). I don't see any way to use that to add an object for keeping track of warned properties.

Using a single object for all would be pretty straightforward, though.

jimfb · 2015-10-13T15:31:10Z

@pluma You're right, looks like it is just using expando; so if you wanted to use instances, you could do something in the same vein. Or just do a single object of css keys; I don't have a strong preference.
cc @spicyj incase he has a preference.

pluma · 2015-10-13T16:02:28Z

@jimfb @spicyj I've added a warning and a test for the warning. I had to add the warning list to the ReactDOMComponent itself though.

facebook-github-bot · 2015-10-13T16:10:20Z

@pluma updated the pull request.

sophiebits · 2015-10-13T17:26:08Z

src/renderers/dom/shared/CSSPropertyOperations.js

   * @return {?string}
   */
-  createMarkupForStyles: function(styles) {
+  createMarkupForStyles: function(styles, context) {


Could you use the name "component" instead? "Context" often means something else (http://facebook.github.io/react/docs/context.html).

sophiebits · 2015-10-13T17:27:14Z

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 ._currentElement._owner.getName() which will be the component that created it. Rendering one component 20 times shouldn't make 20 warnings in the console.

pluma · 2015-10-13T18:23:16Z

@spicyj I would love to do that but in order to warn per component I need to add the _styleWarnings property to all React components (not just ReactDOMComponents). Or maybe I'm just an idiot.

Alternatively I could just do what @jimfb suggested and warn only on the first occurrence globally.

jimfb · 2015-10-13T18:24:48Z

@pluma Ben is suggesting that you call component._currentElement._owner.getName() to get the NAME of the current component (the name will be a string) and use the name of the component as part of your object-key for deduplication.

sophiebits · 2015-10-13T18:26:38Z

See, for example, ReactElementValidator:

react/src/isomorphic/classic/element/ReactElementValidator.js

Lines 104 to 106 in 51c0f86

    
           if (memoizer[addendum]) { 
        
             return null; 
        
           }

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).

pluma · 2015-10-13T18:42:36Z

Okay, I've adjusted the test so it just keeps record locally instead of polluting the components.

facebook-github-bot · 2015-10-13T18:59:48Z

@pluma updated the pull request.

jimfb · 2015-10-13T21:03:01Z

src/renderers/dom/shared/dangerousStyleValue.js

+        }
+      }
+    }
+    return value.trim();


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).

Okay. Should I just revert the original change (i.e. remove the return statement and adjust the tests and docs) then?

Yes, removing the return statement and adjusting the docs sounds good.

facebook-github-bot · 2015-10-14T07:16:38Z

@pluma updated the pull request.

jimfb · 2015-10-14T14:59:53Z

src/renderers/dom/shared/dangerousStyleValue.js

+    if (__DEV__) {
+      if (component) {
+        var owner = component._currentElement._owner;
+        var componentName = owner ? owner.getName() : component._currentElement.type;


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.

jimfb · 2015-10-14T15:01:27Z

src/renderers/dom/shared/dangerousStyleValue.js

@@ -48,7 +51,27 @@ function dangerousStyleValue(name, value) {
  }

  if (typeof value === 'string') {


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.

jimfb · 2015-10-14T15:09:06Z

@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 git rebase -i HEAD^^^^^^ to assist in squashing the commits and then do a git push -f to override the branch rather than adding new commits to it.

pluma · 2015-10-14T16:29:15Z

@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?

facebook-github-bot · 2015-10-14T16:33:37Z

@pluma updated the pull request.

facebook-github-bot · 2015-10-14T16:51:31Z

@pluma updated the pull request.

jimfb · 2015-10-14T18:05:58Z

@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:

We should not warn unless the string value specified is a unitless number in the form of a string. That is to say: it parses as an integer, as oppose to being something like 5px or 5em.
We should not append 'px' unless it is a unitless number. This is a non-breaking change (so we can add it now) because previously it would have resulted in something like 5pxpx or 5empx which would have made no sense.

pluma · 2015-10-14T18:14:48Z

@jimfb both those points are already addressed by the pre-existing isNaN check in line 47 (unlike Number.isNaN, plain isNaN also returns true for values that aren't NaN but don't parse as numbers, like foo or even 4px). The two tests in CSSPropertyOperations-test.js lines 54 onward already test this behaviour.

jimfb · 2015-10-14T18:16:26Z

Ah, got it! Looks good to me.

Fix #1357. Don't append "px" suffix to CSS string values.

jimfb · 2015-10-14T18:19:16Z

@pluma Thanks again!

pluma · 2015-10-14T18:42:19Z

You're welcome.

matthetherington · 2016-04-19T10:59:55Z

I'm getting a ton of warnings since upgrading to 15.0.1 due to this.

We have styles such as margin: '0' or top: '0' throughout our codebase - shouldn't the warning be skipped for zero values? The unit suffix is optional for zero values as per the CSS spec:

https://www.w3.org/TR/CSS2/syndata.html#length-units

I'll be happy to submit a PR if this is something wanted.

gaearon · 2016-04-19T11:10:43Z

We have styles such as margin: '0' or top: '0' throughout our codebase - shouldn't the warning be skipped for zero values?

Yes, this was merged, just isn’t out yet. See #6458.

matthetherington · 2016-04-19T11:13:03Z

Ah sweet.

facebook-github-bot added GH Review: review-needed CLA Signed labels Oct 12, 2015

sophiebits reviewed Oct 13, 2015
View reviewed changes

sophiebits added GH Review: needs-revision and removed GH Review: review-needed labels Oct 13, 2015

facebook-github-bot added GH Review: review-needed and removed GH Review: needs-revision labels Oct 13, 2015

jimfb reviewed Oct 13, 2015
View reviewed changes

jimfb reviewed Oct 14, 2015
View reviewed changes

pluma force-pushed the patch-1 branch from 999b70a to 69e677e Compare October 14, 2015 16:28

Fix facebook#1357. Warn when appending "px" to strings.

a299a36

pluma force-pushed the patch-1 branch from 69e677e to a299a36 Compare October 14, 2015 16:36

pluma mentioned this pull request Oct 14, 2015

Issue: 5013 Added necessary code for firing warning if value is null #5048

Merged

jimfb added GH Review: accepted and removed GH Review: review-needed labels Oct 14, 2015

jimfb added a commit that referenced this pull request Oct 14, 2015

Merge pull request #5140 from pluma/patch-1

555fd46

Fix #1357. Don't append "px" suffix to CSS string values.

jimfb merged commit 555fd46 into facebook:master Oct 14, 2015

pluma deleted the patch-1 branch October 14, 2015 18:42

joshdover mentioned this pull request Apr 18, 2016

use react 15.0.1 casesandberg/react-color#132

Closed

kylecesmat mentioned this pull request Jul 1, 2016

Update React & Radium FormidableLabs/spectacle-docs#14

Merged

renovate bot mentioned this pull request Feb 2, 2018

Update dependency react to v0.14.9 - autoclosed signavio/backbone-rel#29

Closed

1 task

		@@ -48,7 +51,27 @@ function dangerousStyleValue(name, value) {
		}

		if (typeof value === 'string') {

Fix #1357. Don't append "px" suffix to CSS string values. #5140

Fix #1357. Don't append "px" suffix to CSS string values. #5140

Conversation

pluma commented Oct 12, 2015

jimfb commented Oct 12, 2015

sophiebits commented Oct 12, 2015

pluma commented Oct 12, 2015

sophiebits commented Oct 12, 2015

pluma commented Oct 12, 2015

sophiebits commented Oct 12, 2015

pluma commented Oct 12, 2015

jimfb commented Oct 12, 2015

pluma commented Oct 13, 2015

jimfb commented Oct 13, 2015

pluma commented Oct 13, 2015

facebook-github-bot commented Oct 13, 2015

sophiebits Oct 13, 2015

Choose a reason for hiding this comment

sophiebits commented Oct 13, 2015

pluma commented Oct 13, 2015

jimfb commented Oct 13, 2015

sophiebits commented Oct 13, 2015

pluma commented Oct 13, 2015

facebook-github-bot commented Oct 13, 2015

jimfb Oct 13, 2015

Choose a reason for hiding this comment

pluma Oct 14, 2015

Choose a reason for hiding this comment

jimfb Oct 14, 2015

Choose a reason for hiding this comment

facebook-github-bot commented Oct 14, 2015

jimfb Oct 14, 2015

Choose a reason for hiding this comment

pluma Oct 14, 2015

Choose a reason for hiding this comment

jimfb Oct 14, 2015

Choose a reason for hiding this comment

jimfb commented Oct 14, 2015

pluma commented Oct 14, 2015

facebook-github-bot commented Oct 14, 2015

facebook-github-bot commented Oct 14, 2015

jimfb commented Oct 14, 2015

pluma commented Oct 14, 2015

jimfb commented Oct 14, 2015

jimfb commented Oct 14, 2015

pluma commented Oct 14, 2015

matthetherington commented Apr 19, 2016

gaearon commented Apr 19, 2016

matthetherington commented Apr 19, 2016