Use setProperty when setting style properties

[aweary]

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]

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

[trueadm]

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

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

[trueadm]

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

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]

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

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]

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

[aweary]

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]

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]

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

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

[aweary]

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

Have you verified this works in a browser?

[gaearon]

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

[aweary]

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

great, feel free to merge :)

[thysultan]

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