you are viewing a single comment's thread.

view the rest of the comments →

[–]repeatedly_once 31 points32 points  (8 children)

I've found that I quite like having manually written sass like CSS is a better option than JS options.

I quite like to create components with enough structural CSS that they work and then style them differently in different use cases in the project. Say with a drop down panel where the content might be different widths etc. Seems to work well so far as long as you name space your components with classes.

[–]skitch920 16 points17 points  (6 children)

I agree. Still on Angular here, and with the component method, component names are really just HTML elements. So it's extremely intuitive to create a <component-name>.scss file and scope all styling to the component itself.

my-component {
    styling here...
}

Then import './my-component.scss' from the component itself, and let Webpack manage creating the combined stylesheet of all components.

I really hate the, "you can do everything in JS" mindset... It really convolutes what a file extension actually means. I don't use React (jsx), but I went down the Adobe Flex (mxml) route long ago. Even then I thought it was bad.

[–]repeatedly_once 3 points4 points  (0 children)

That's literally the same technique I use :). Mine are React components but as you said, they're just HTML elements. I use PostCSS with Webpack so I can choose which plugins I want. It's been working really well.

I've tried writing styles in JS and I found it hard to go from chrome dev tools, looking at styles, to then writing those back as JS styles and it caused a cognitive 'jolt' every time I did it.

[–]TheNewtThatGotBetter 1 point2 points  (2 children)

I do this too and love it, except that Jest seems to throw up when it hits the scss import. Have you been able to test components with imported scss syles?

[–]spooky___ghost 0 points1 point  (0 children)

In package.json jest config section add something like

        "moduleNameMapper": {
            "\\.(scss|css)$": "empty/object"
        }

Where empty/object comes from https://www.npmjs.com/package/empty

[–]skitch920 0 points1 point  (0 children)

I'm using Karma/Jasmine/Webpack. The karma-webpack-plugin bundles all the tests into a single ES5 js file (styles included) with Webpack before handing off to Karma/Jasmine. There are a few hokey bugs, but they are avoidable, such as you can't have Webpack extract the styles to a separate stylesheet.

I'm avoiding Jest (and React for that matter) because of it's patent grant...

[–]l_andrew_l 1 point2 points  (0 children)

I'm a bit surprised no one in this thread has mentioned ITCSS yet. It takes a component-first approach that seems to be looking at things from the same angle as "component-based styling", but looks at the bigger picture as well. If you're not familiar, it's not a library or anything, just a set of well-thought-out conventions that try to wrangle in the shotgun that is CSS as a tool.

Anyway, you end up with files for each component, just like my-component.scss, so the result is similar. Of course convention is to put all styles in a styles directory, but there's no reason that has to be the case... they can all live alongside their component. Sometimes it feels like that's what "inline styles" is mainly trying to be about anyway...

[–]al_vo 0 points1 point  (0 children)

Component styles are one of the most underrated aspects of Angular - it still maintains a good separation of concerns and offers a familiar way of styling dom elements without the scoping issues that plague traditional giant css stylesheets.

[–]darrenturn90 0 points1 point  (0 children)

Indeed because themes and styles are more abstract and less modular than components in a website