[au-arms]

Clever, but this smells like a performance anti-pattern. Adopting this means you could, at worst, add 4 spacer divs per component. While most sites may never really feel a sting, for complex apps where reusability is a larger concern you've doubled to quadrupled the size of an already large DOM and you will be hit a death-by-one-thousand-cuts situation.

Now you've got more...

- html over the wire

- html to parse for first render

- DOM nodes to mount/unmount

- memory usage from excess DOM

- costly layouts due to extra nodes

- lighthouse complaints of an excessively large DOM

Otherwise a clean approach. Perhaps it could be solved at compile time or some other jsx -> CSS abstraction to maintain DX.

[FinalBriefing]

I saw a blog post a while back from a React developer who did this. They didn't use padding or margins, just `<div>` elements with an exact height and width. I fail to see any benefits of doing it that way...just learn and use CSS.

I'm not sure if that's what this post is suggesting, though.

[s-lambert]

Why do you need to add spacer divs? As long as the child components accept classes as props then the styling comes from the parent but is still applied on the children.

[FloNeu]

You can also apply margin via element and nth-child selectors, just as a note... Also - custom/shadow dom elements should allow classes - I think it doesn't work in angular yet - but should arrive in the next version(?). Also you could just use ::before ::after pseudo selectors instead of divs...

[smarkov]

If you're worried about a few additional elements your DOM is already too big and you have bigger issues to worry about.

[thomasahle]

Can't you just use the spacing properties of the container? Like flexbox's space-around and space- between?

[au-arms]

You can, however the lack of constraints on the spacing can make it difficult to match strict design systems. The dependence the spacing creates on the parent & child dimensions can lead to undesirable edge cases as well for dynamic/responsive content.

[kylemh]

The opposite would be the intent and the goal. Align design system language WITH your spacer components ensuring strict adherence. Layout components work and they don't have performance issues.

[au-arms]

I think we agree here. The argument I am making is that spacer components that introduce DOM bloat can negatively impact large apps, especially on low power devices.

A layout component does not have to introduce DOM bloat, it could apply layout directly via CSS to it's children. Layout components in this regard are incredibly helpful.

[bryanrasmussen]

I also think repaints are probably more expensive given this solution.

[au-arms]

More expensive with or without the spacer components?

[bryanrasmussen]

I would think more expensive with spacers, you have more nodes to repaint, furthermore if you have an event that changes a particular spacer size - for example if you have contentnode spacernode contentnode and then change width of spacernode you will be repainting three nodes. Window resizing becomes more expensive seems to me.

[kadoban]

Probably more expensive with spacers? I'd like to see some benchmarks though, I'm doing little more than guessing.