Radium: Adding userAgent config to Radium makes it not rerender styles that need prefixing

Created on 20 Feb 2016  路  10Comments  路  Source: FormidableLabs/radium

Quick example.

import React, { Component } from 'react';
import Radium from 'radium';

class toggler extends Component {
  componentWillMount() {
    this.showHeading();
  }

  showHeading() {
    this.setState({style: {
      display: 'flex',
      color: 'red',
    }});
  }

  hideHeading() {
    this.setState({style: {
      display: 'none',
      color: 'blue',
    }});
  }

  render() {
    return (
      <div>
        <button onClick={this.hideHeading.bind(this)}>hide it</button>
        <button onClick={this.showHeading.bind(this)}>show it</button>
        <h1 key="h2" style={this.state.style}>Hide and show me</h1>
        <div>current style state: {JSON.stringify(this.state.style)}</div>
      </div>
    );
  }
}

export default Radium({ userAgent: 'all' })(toggler);

Expected beahviour:
1- h1 element starts with all prefixed display: 'flex'
2- click hide element, changes display to none and color to blue
3- click show element, changes display to flex and all its prefixes, and change color to red.

Actual:
1- h1 element starts with all prefixed display: 'flex'
2- click hide element, changes display to none and color to blue
3- click show element, display stays none, but color changes to red

bug high priority

Most helpful comment

@ianobermiller Do you have any update on this issue? Since updating react to 0.15.x, it does not support innerHTML anymore instead uses createElement. Specially when using display: "flex" the styles are rendered not rendered when the view changes inside react component. I am facing the similar problem as stated in the OP's question.

All 10 comments

Not sure if https://github.com/rofrischmann/inline-style-prefixer issue. @rofrischmann ?

As the prefixing seems to be working correctly, I'd tend to say this is an issue not with the prefixer itself.

That is quite interesting. I created a simple bin to reproduce this here: https://jsbin.com/cemequ/edit?html,js,console,output

As far as I can tell, Radium is updating the style prop correctly, this _could_ be a React bug. If I look at the repro using the inspector, it tells me that React is getting the correct style prop. Perhaps it is just not applying it correctly?

I'm also seeing this with React 15.0.1. When rendering on server side, display: flexis there, but when component is rendered on client side, it's omitted for some reason. We are using <StyleRoot radiumConfig={{userAgent: "all"}}> in root component.

With React 15+ string-based alternative values are no longer supported (they've never been supported officially). The reason is that React now uses document.createElement instead of innerHTML to do initial rendering/mounting. It actually is not even React that "removes" the property, but your browser itself as it is an unsupported value.
That said I guess relying on pure Inline Styles won't work as it has up to React 0.14.x. At least you would need to use another mechanism to check for supported property values (and vendor prefixes).

Guess this might be really interesting for the future of Radium (and other Inline Styles libraries as well), @ianobermiller @alexlande

Oof. This could be tricky. Might be another good reason to investigate using addCSS for everything as discussed in https://github.com/FormidableLabs/radium/issues/510.

@ianobermiller Do you have any update on this issue? Since updating react to 0.15.x, it does not support innerHTML anymore instead uses createElement. Specially when using display: "flex" the styles are rendered not rendered when the view changes inside react component. I am facing the similar problem as stated in the OP's question.

Same here but with the prefixed transition property.

There's some movement in React that would help with this: https://github.com/facebook/react/pull/6701

Open to alternatives in the meantime. Some possibilities are:

  • Using addCSS for everything (this is bound to come with its own problems and would take considerable effort)
  • Use a different mechanism for applying fallback values, as @rofrischmann mentioned. Not clear how exactly we would handle that one.

I'm having hard time to workaround this issue. Does anyone find a good way?

Was this page helpful?
0 / 5 - 0 ratings