[aphextron]

>In this scenario, you can add props/params to override defaults.

Of course. But why? You're just adding complexity at that point. It's the same problem with frameworks like Bootstrap that use complex combinations of class names for styling. Now instead of having a semantic BEM style class name on the component that I can look up in a stylesheet and modify, I have to memorize an entire framework of esoteric 'col-md-whatever' class names and know how/where/when to apply them. It adds a massive cognitive load beyond just using CSS. In the instance of a custom spacer component described above, I'm now also on the hook for documenting and testing a component that is entirely visual, rather than just writing a couple lines of CSS.

[baddox]

Well then what’s the alternative? Using the same spacer component everywhere is bad because the designer might want to change the spacing in only one spot? Okay. But what if the designer wants to change the spacing in all spots? That’s a much more likely scenario in my experience, but the point is you need to be able to do both.

[aphextron]

The point is that layout should be handled at the highest level possible. Have a CSS file at the application shell component level which defines a baseline margin and grid for components, then have individual page component level CSS that can tweak those layouts where needed. Actual UI components should then only ever need to use padding.