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

Use setProperty when setting style properties #9302

Merged
merged 5 commits into from Apr 20, 2017

Conversation

Projects
None yet
8 participants
@aweary
Member

aweary commented Mar 31, 2017

Work in progress. Resolves #6411

Using setProperty does incur the cost of parsing the style name as setProperty requires the hyphenated property name (background-color not backgroundColor). I'm also not sure if we want to special case IE given the performance benefits mentioned #6411 (comment)

cc @trueadm @sebmarkbage @spicyj

@sebmarkbage

This comment has been minimized.

Show comment
Hide comment
@sebmarkbage

sebmarkbage Mar 31, 2017

Member

It seems like going down this route would inevitably involve a change from camelCase to hyphenation by convention. Probably including React Native then.

Member

sebmarkbage commented Mar 31, 2017

It seems like going down this route would inevitably involve a change from camelCase to hyphenation by convention. Probably including React Native then.

@trueadm

This comment has been minimized.

Show comment
Hide comment
@trueadm

trueadm Mar 31, 2017

Contributor

@sebmarkbage I'm a fan of dropping the camelCase conventions if we can going forward (we can transform them for initial releases with warnings) for RN too. Keeping them closer to true "CSS" helps reduce friction.

Contributor

trueadm commented Mar 31, 2017

@sebmarkbage I'm a fan of dropping the camelCase conventions if we can going forward (we can transform them for initial releases with warnings) for RN too. Keeping them closer to true "CSS" helps reduce friction.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Mar 31, 2017

Member

It’s more awkward to type though unless you provide some compile-time helper. Also more awkward to transform in JS.

Member

gaearon commented Mar 31, 2017

It’s more awkward to type though unless you provide some compile-time helper. Also more awkward to transform in JS.

@trueadm

This comment has been minimized.

Show comment
Hide comment
@trueadm

trueadm Mar 31, 2017

Contributor

@gaearon We could do something nice at compile-time to help people here. We could also simply avoid passing an object literal too and let people pass in a block of cssText.

Contributor

trueadm commented Mar 31, 2017

@gaearon We could do something nice at compile-time to help people here. We could also simply avoid passing an object literal too and let people pass in a block of cssText.

@aweary

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary Mar 31, 2017

Member

Personally, I prefer the camelCase convention as its consistent with the DOM prop APIs like className and htmlFor. If this change necessitates changing the style API I would be less enthusiastic about adopting it, I don't think the churn it would require in React styling community projects would be worth it.

Member

aweary commented Mar 31, 2017

Personally, I prefer the camelCase convention as its consistent with the DOM prop APIs like className and htmlFor. If this change necessitates changing the style API I would be less enthusiastic about adopting it, I don't think the churn it would require in React styling community projects would be worth it.

@trueadm

This comment has been minimized.

Show comment
Hide comment
@trueadm

trueadm Mar 31, 2017

Contributor

@aweary In my opinion, this has always been one of the harder things for newcomers to understand, especially className vs class. It's led to countless bugs and confusion in the teams I've worked in when using React in big companies at scale. I'm mixed on this.

Contributor

trueadm commented Mar 31, 2017

@aweary In my opinion, this has always been one of the harder things for newcomers to understand, especially className vs class. It's led to countless bugs and confusion in the teams I've worked in when using React in big companies at scale. I'm mixed on this.

@milesj

This comment has been minimized.

Show comment
Hide comment
@milesj

milesj Apr 1, 2017

Contributor

Why not do the name conversion at the JSX compiler level?

<span style={{ backgroundColor: 'red', 'border-color': 'blue' }}>
  Foo
</span>
React.createElement('span', {
  style: { 'background-color': 'red', 'border-color': 'blue' },
}, 'Foo');
Contributor

milesj commented Apr 1, 2017

Why not do the name conversion at the JSX compiler level?

<span style={{ backgroundColor: 'red', 'border-color': 'blue' }}>
  Foo
</span>
React.createElement('span', {
  style: { 'background-color': 'red', 'border-color': 'blue' },
}, 'Foo');
@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Apr 1, 2017

Member

Because you can't know something is a style if it's passed around.

Member

gaearon commented Apr 1, 2017

Because you can't know something is a style if it's passed around.

@aweary

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary Apr 4, 2017

Member

Can we consider accepting this without updating the public API for now? Assuming the cost of transforming the names is minimal (they're memoized so it should be in most cases). It would close #6411

Member

aweary commented Apr 4, 2017

Can we consider accepting this without updating the public API for now? Assuming the cost of transforming the names is minimal (they're memoized so it should be in most cases). It would close #6411

@sebmarkbage

This comment has been minimized.

Show comment
Hide comment
@sebmarkbage

sebmarkbage Apr 4, 2017

Member

We need to benchmark this. I don't think we'll want to take a significant hit. The memoized forms still needs to be looked up in a map which is not free. If we want to support #6411 a safer bet might be to just check if it starts with --.

Member

sebmarkbage commented Apr 4, 2017

We need to benchmark this. I don't think we'll want to take a significant hit. The memoized forms still needs to be looked up in a map which is not free. If we want to support #6411 a safer bet might be to just check if it starts with --.

@aweary

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary Apr 4, 2017

Member

@sebmarkbage I'll benchmark before we move any further. setProperty can also perform better per discussion in #6411 so the cost of the map lookup might be offset. But we still might want to do env detection or just use style as setProperty is significantly slower in <IE11 and some others

Member

aweary commented Apr 4, 2017

@sebmarkbage I'll benchmark before we move any further. setProperty can also perform better per discussion in #6411 so the cost of the map lookup might be offset. But we still might want to do env detection or just use style as setProperty is significantly slower in <IE11 and some others

@sophiebits

This comment has been minimized.

Show comment
Hide comment
@sophiebits

sophiebits Apr 7, 2017

Member

I think for now it makes sense to call .setProperty for names starting with -- and leave everything else the same.

Member

sophiebits commented Apr 7, 2017

I think for now it makes sense to call .setProperty for names starting with -- and leave everything else the same.

@aweary

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary Apr 9, 2017

Member

@spicyj @sebmarkbage I've updated it so that only properties starting with -- are set using setProperty. I also added a test ensuring it doesn't warn. I tried testing that the variable was actually being set correctly, but jsdom doesn't appear to fully support CSS variables yet.

Member

aweary commented Apr 9, 2017

@spicyj @sebmarkbage I've updated it so that only properties starting with -- are set using setProperty. I also added a test ensuring it doesn't warn. I tried testing that the variable was actually being set correctly, but jsdom doesn't appear to fully support CSS variables yet.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Apr 18, 2017

Member

Have you verified this works in a browser?

Member

gaearon commented Apr 18, 2017

Have you verified this works in a browser?

@gaearon

Looks good to me but please verify it works in the browser.

@gaearon gaearon added this to the 15-hipri milestone Apr 18, 2017

@flarnie flarnie referenced this pull request Apr 18, 2017

Closed

React 15.6 Umbrella #9398

41 of 49 tasks complete
@aweary

This comment has been minimized.

Show comment
Hide comment
@aweary

aweary Apr 20, 2017

Member

@gaearon I did, I tested in in Chrome, Firefox and Safari on macOS and both styles with CSS variables and styles without were set as expected. I also tested in IE9-11 and Android 4 and verified the styles that didn't use CSS variables were being set as expected.

Member

aweary commented Apr 20, 2017

@gaearon I did, I tested in in Chrome, Firefox and Safari on macOS and both styles with CSS variables and styles without were set as expected. I also tested in IE9-11 and Android 4 and verified the styles that didn't use CSS variables were being set as expected.

@sophiebits

This comment has been minimized.

Show comment
Hide comment
@sophiebits

sophiebits Apr 20, 2017

Member

great, feel free to merge :)

Member

sophiebits commented Apr 20, 2017

great, feel free to merge :)

@aweary aweary merged commit 42bc28b into facebook:master Apr 20, 2017

1 check passed

ci/circleci Your tests passed on CircleCI!
Details
@thysultan

This comment has been minimized.

Show comment
Hide comment
@thysultan

thysultan Apr 24, 2017

@aweary You could do the following to also support both camelCase and dash-cased styles.

var style = props.style;

for (...) {
    if (name in DOMStyleObject) {
        DOMStyleObject[name] = style[name];
    } else {
        DOMStyleObject.setProperty(name, style[name]);
    } 
}

Edit: though ^^ might not be the best for performance.

thysultan commented Apr 24, 2017

@aweary You could do the following to also support both camelCase and dash-cased styles.

var style = props.style;

for (...) {
    if (name in DOMStyleObject) {
        DOMStyleObject[name] = style[name];
    } else {
        DOMStyleObject.setProperty(name, style[name]);
    } 
}

Edit: though ^^ might not be the best for performance.

flarnie added a commit that referenced this pull request May 3, 2017

Use setProperty when setting style properties (#9302)
* Use setProperty when setting style properties

setProperty is faster in all/most modern browsers. It also lets us support CSS variables.

* Only use setProperty when setting CSS variables

* Add test to ensure setting CSS variables do not warn

* Make this PR pretty again

* Run fiber test script

flarnie added a commit to flarnie/react that referenced this pull request Jun 6, 2017

Add PR #9302 to 15.6RC CHANGELOG
Just keeping things updated.

facebook#9398

flarnie added a commit that referenced this pull request Jun 6, 2017

Add PR #9302 to 15.6RC CHANGELOG (#9857)
Just keeping things updated.

#9398

flarnie added a commit to flarnie/react that referenced this pull request Jun 7, 2017

Use setProperty when setting style properties (#9302)
* Use setProperty when setting style properties

setProperty is faster in all/most modern browsers. It also lets us support CSS variables.

* Only use setProperty when setting CSS variables

* Add test to ensure setting CSS variables do not warn

* Make this PR pretty again

* Run fiber test script

@renovate renovate bot referenced this pull request Feb 2, 2018

Open

Update dependency react to v16 #29

@frenic frenic referenced this pull request Apr 11, 2018

Merged

[React] Remove string index fallback for CSS properties #24911

5 of 9 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment