Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CSS Modules

glenmaddern.com

Post reply on HN
Print view View original

31–40 of 93 posts

Re: CSS Modules

#31

Post by andrewingram »

aleem wrote: post #29

It's wonderful that CSS problems have been distilled so clearly, it's been a long time coming. Radium[1] is really worth checking out, it's simple and clear. From the article: /* BEM */ .normal { /* all styles for Normal */ } .button--disabled { /* overrides for Disabled */ } .button--error { /* overrides for Error */ } .button--in-progress { /* overrides for In Progress */ /* CSS MODULES */ .normal { /* all styles f…

Except as far as I can tell, with Radium you get zero support for pseudo classes and media queries until after the client-side JavaScript has downloaded and been initialised. This is acceptable if it's purely a client-side app, but if you're using an kind of server-side rendering it's clearly not good enough.

I really don't want a lack of hover or focus effects on initial page load, and I really don't want my entire page layout to change once the JavaScript-powered media queries kick in.

Re: CSS Modules

#32

Post by aleem »

andrewingram wrote: post #31
aleem wrote: post #29

It's wonderful that CSS problems have been distilled so clearly, it's been a long time coming. Radium[1] is really worth checking out, it's simple and clear. From the article: /* BEM */ .normal { /* all styles for Normal */ } .button--disabled { /* overrides for Disabled */ } .button--error { /* overrides for Error */ } .button--in-progress { /* overrides for In Progress */ /* CSS MODULES */ .normal { /* all styles f…

Except as far as I can tell, with Radium you get zero support for pseudo classes and media queries until after the client-side JavaScript has downloaded and been initialised. This is acceptable if it's purely a client-side app, but if you're using an kind of server-side rendering it's clearly not good enough. I really don't want a lack of hover or focus effects on initial page load, and I really don't want my entire…

Radium is simple, for that I like it. Complexity comes with a price and there may be alternatives but Radium leverages JS expressions which I like. Quoting from the article again:

  /* components/submit-button.jsx */
  import { Component } from 'react';
  import styles from './submit-button.css';
  
  export default class SubmitButton extends Component {
    render() {
      let className, text = "Submit"
      if (this.props.store.submissionInProgress) {
        className = styles.inProgress
        text = "Processing..."
      } else if (this.props.store.errorOccurred) {
        className = styles.error
      } else if (!this.props.form.valid) {
        className = styles.disabled
      } else {
        className = styles.normal
      }
      return {text}
    }
  }
That looks unwieldy -- 4 if/else clauses just to deal with CSS. Contrast that with the example in "Usage" over at the Radium page https://github.com/FormidableLabs/radium -- much simpler.

Re: CSS Modules

#33

Post by merrywhether »

aleem wrote: post #29

It's wonderful that CSS problems have been distilled so clearly, it's been a long time coming. Radium[1] is really worth checking out, it's simple and clear. From the article: /* BEM */ .normal { /* all styles for Normal */ } .button--disabled { /* overrides for Disabled */ } .button--error { /* overrides for Error */ } .button--in-progress { /* overrides for In Progress */ /* CSS MODULES */ .normal { /* all styles f…

Regarding your first point, he addresses that in the next section:

"The composes keyword says that .normal includes all the styles from .common, much like the @extends keyword in Sass. But while Sass rewrites your CSS selectors to make that happen, CSS Modules changes which classes are exported to JavaScript."

And isn't file (module) naming and directory structure what we use to organize regular code? I like the idea of going to the components folder and looking for the 'submit button' file when I need to alter something much more than searching a 20,000 line css file or randomly split scss files. Even nicer is the concept of including your styles in the same directory as the components they define, further mirroring normal code organization. It seems like this would allow for much easier onboarding into a project.

Re: CSS Modules

#34

Post by dantillberg »

egze wrote: post #26

The advantage of BEM naming is that it takes 0 effort to find your style definitions in code. .Button--disabled copied in the browser, will find exactly 1 definition in the project. .components_submit_button__normal__abc5436 will not find you anything.

But on the flipside, in the latter case, you don't even need to grep for it -- "components_submit_button__normal__abc5436" reads as "components_{filename}_{classname}...", so you know right away to go look in "submit_button.(css|less|etc)" for ".normal {...".

Re: CSS Modules

#35

Post by pauly »

troels wrote: post #25

Abstractions are fine and dandy until they break down and you have to pry them open. What I don't understand here, is why the generated code doesn't follow the already established BEM conventions which the posts explores initially.

I'm with you, that generated css doesn't look right, something that generated the css BEM style makes more sense.

Re: CSS Modules

#36

Post by aleem »

merrywhether wrote: post #33
aleem wrote: post #29

It's wonderful that CSS problems have been distilled so clearly, it's been a long time coming. Radium[1] is really worth checking out, it's simple and clear. From the article: /* BEM */ .normal { /* all styles for Normal */ } .button--disabled { /* overrides for Disabled */ } .button--error { /* overrides for Error */ } .button--in-progress { /* overrides for In Progress */ /* CSS MODULES */ .normal { /* all styles f…

Regarding your first point, he addresses that in the next section: "The composes keyword says that .normal includes all the styles from .common, much like the @extends keyword in Sass. But while Sass rewrites your CSS selectors to make that happen, CSS Modules changes which classes are exported to JavaScript." And isn't file (module) naming and directory structure what we use to organize regular code? I like the idea…

I am not saying it's a bad idea. However, it trades one set of problems for another. What point is there in highlighting a problem and then proposing a remedy which introduces the same problems in a different form?

> I like the idea of going to the components folder and looking for the 'submit button'

All existing frameworks use the same approach (Bootstrap, Foundation, et al). GetMDL.io for example uses BEM and clean files to organize code https://github.com/google/material-design-lite/tree/master/s...

Dealing with that on any reasonably sized project still requires "naming discipline" and "cognitive effort", both of which the author highlights as problems ailing BEM with a remedy that still suffer from the same. It didn't read very convincingly.

Re: CSS Modules

#37

Post by egze »

dantillberg wrote: post #34
egze wrote: post #26

The advantage of BEM naming is that it takes 0 effort to find your style definitions in code. .Button--disabled copied in the browser, will find exactly 1 definition in the project. .components_submit_button__normal__abc5436 will not find you anything.

But on the flipside, in the latter case, you don't even need to grep for it -- "components_submit_button__normal__abc5436" reads as "components_{filename}_{classname}...", so you know right away to go look in "submit_button.(css|less|etc)" for ".normal {...".

This is certainly a less convenient approach. You always need to parse the class name in your head to open the correct file.

Re: CSS Modules

#39

Post by andrewingram »

aleem wrote: post #32
andrewingram wrote: post #31

Earlier quoted context omitted.

Except as far as I can tell, with Radium you get zero support for pseudo classes and media queries until after the client-side JavaScript has downloaded and been initialised. This is acceptable if it's purely a client-side app, but if you're using an kind of server-side rendering it's clearly not good enough. I really don't want a lack of hover or focus effects on initial page load, and I really don't want my entire…

Radium is simple, for that I like it. Complexity comes with a price and there may be alternatives but Radium leverages JS expressions which I like. Quoting from the article again: /* components/submit-button.jsx */ import { Component } from 'react'; import styles from './submit-button.css'; export default class SubmitButton extends Component { render() { let className, text = "Submit" if (this.props.store.submissionI…

If we were to mirror the approach of the Radium example, we'd actually end up with something more like this:

  import React from 'React';
  import styles from './SubmitButton.css';

  class SubmitButton extends Component {
    defaultProps = {
      kind: 'default'
    }
    
    render() {
      const { kind } = this.props;
      const text = kind === 'in-progress' ? 'Processing...' : 'Submit';
      
      return {text}
    }
  }
Post reply on HN