override-style.js

var styles = StyleSheet.create({
  wrapper: {
    // ...
  },
  text: {
    // ...
  }
})
var Button = React.createClass({
  render() {
    return (
      <View style={[styles.wrapper, this.props.style]}>
        <Text style={styles.text}>{this.props.children}</Text>
      </View>
      );
  }
});


var MoreCustomButtonOptionOne = React.createClass({
  render() {
    return (
      <View style={[styles.wrapper, this.props.style]}>
        <Text style={[styles.text, this.props.textStyle]}>{this.props.children}</Text>
      </View>
      );
  }
})

var MoreCustomButtonOptionTwo = React.createClass({
  render() {
    var { color, fontSize, ...style } = this.props.style || {};
    var textStyle = { color, fontSize };
    
    return (
      <View style={[styles.wrapper, style]}>
        <Text style={[styles.text, textStyle]}>{this.props.children}</Text>
      </View>
      );
  }
})

What if you wanted to add a prop for the <Text> element? What do you name that prop? What if there are two children? What do you name those props?

@joeybaker good questions. I added 2 more examples for the text style... I prefer the first because I think the latter is a more confusing API to whoever is using these buttons. These issues are more pronounced in React Native since only nodes can render text. In web it's not as big of a deal, although web presents some other issues.

For "multiple children", you can enforce that a user passes in only one child using React.PropTypes.node. In Web it wouldn't really matter since there is no concept of a node...

Yea, I see where you're going. I just think this is where CSS wins out. The equivalent of View Text { …styles… } (if CSS were in react native) would be easier to use than props once you get to several children IMHO.

Hmm... I understand where you are coming from but I disagree. I think I'm going to write a blog post articulating why exactly, because I think it's subtle.

Our experience with a very visually heavy website with about a hundred of components told us that the props are the only sane way to scale. If you take shortcuts like using CSS cascade, it's so damn hard to move components around and change them later. You get all sorts of implicit dependencies. On the other hand, when props are the only contract to your component, you can even work on them in isolation. It feels so right, and once you try it, you're never going back to CSS cascade hell.

One shortcut we've been taking is a context prop that is more “flexible”, e.g. <Button context='thatDamnPopupMenu'> that becomes .Button--isInThatDamnPopupMenu. This kinda couples the components, but sometimes there's no way to avoid coupling. Like if there's only one place in the app where button's styles are different (usually due to layout) and you can't make up a prop that makes more sense than a generic context. Still, it is absolutely explicit and defined inside Button, so this coupling is visible and colocated with the rest of the Button styles.