[Layout] styling specificity using > disallows easy override via classname

[rosskevin]

Description

Layout specificity of padding disallows use of override via className

e.g. .Layout-gutter-xs-16-3374265422 > .Layout-typeItem-565831246

Generated by this code.

Problem description

Link to minimally-working code that reproduces the issue

// @flow
import React, {PropTypes, Element} from 'react'
import {createStyleSheet} from 'jss-theme-reactor'
import {Container, Item} from 'material-ui/Layout'

export const styleSheet = createStyleSheet('LayoutGutterPaddingOverride', () => {
  return {
    hero: {
      padding: '60px 30px',
    },
  }
})

type Props = {}

const LayoutGutterPaddingOverride = (props: Props, context: {styleManager: Object}): Element<any> => {
  const classes = context.styleManager.render(styleSheet)
  return (
    <Layout container direction='column'>
      <Layout item className={classes.hero}>
        <h1>Some Heading</h1>
      </Layout>
    </Layout>
  )
}

LayoutGutterPaddingOverride.contextTypes = {
  styleManager: PropTypes.object.isRequired
}

export default LayoutGutterPaddingOverride

Versions

• Material-UI: next
• React:
• Browser:

[oliviertassinari]

I'm not sure what to answer about that point. We use that CSS feature (.Layout-gutter-xs-16-3374265422 > .Layout-typeItem-565831246) in order to speed up the React rendering.
Otherwise, we should have to clone every children.
It's a known limitation, I don't see a better tradeoff.

[rosskevin]

This relates to #6013 (comment) in that if we need to split components for a more concrete props API, it might affect the approach.

[rosskevin]

@oliviertassinari can you point me to information on cloneElement performance? How about alternative patterns? I'd like to come to a better understanding so I don't inadvertently introduce non-performant code. I've seen this jsperf createElement vs cloneElement.

[oliviertassinari]

@rosskevin I don't think that we can compare createElement performance against cloneElement as they are not interchangeable. No matter the approach, you gonna have to call a createElement at least once.

• Option 1: you use React idiomatic pattern by iterating and cloning each of them do add the right gutter property through the children.
• Option 2: you use CSS inheritance as it's done here.

We have been using option 1 on the master branch, as highlighted with #2787, that don't perform well. Have a look at the implementation of Children.map and cloneElement. A lot is going on under the hood. I believe that we are at a point where increasing the specificity and taking advantage of the CSS power worth it.

[oliviertassinari]

I'm closing the issue. I'm expecting other people to raised that point. We will see if someone have a better tradeoff to propose.

@rosskevin Thanks for asking.

[oliviertassinari]

I just came into another case where this CSS inheritance is really useful. Consider using react-virtualized to lazy rendering the children item while the parent is a container. Option 1 won't be possible.