Components: Spacer props on all components by default?

I’ve been tinkering with prototypes with @sixhours .

An interesting point was brought up in regards to <Spacer /> props (e.g. m={5}) not being available on other components. Other components instead have to use css for margin/padding adjustments.

Originally, I had thought that <Spacer /> would be the primary way to space things apart. If you ever need margin/padding for something, use/wrap it with <Spacer />. Direct css styling would be reserved for more override-like scenarios.

Would could try another approach… where all of the <Spacer /> props like mx, my, etc… are available to all components (via <View />) by default.

So for example, this would work:

<Card mb={3}>...</Card>

Whereas right now, we would do this:

<Spacer mb={3}>
  <Card>...</Card>
</Spacer>

I think performance gains would be negligible. It’s more about what feels more intuitive from a DX perspective.

Open to thoughts!

cc’ing @lcollette @MichaelArestad @diegohaz

P.S. Having inline css props for styling (e.g. m) isn’t a unique ideas. Libraries Chakra support this feature

[ItsJonQ]

Sharing a thought here that I just had!

Taking a step back… Ideally, folks wouldn’t need to do (much) micro adjustment of margin/padding. UI components (e.g. TextInput, Card, etc…) shouldn’t really have margins begin with.

Spacing can be added when using them within Layout based components, like HStack, or Grid.

(Think of the “Autolayout” feature in Figma)

In other words… you shouldn’t need to fiddle with spacing. If you do, it’s an explicit choice. Therefore, there should be a dedicated solution (Component) for that (e.g. Spacer).

With that being said…

Should we prevent consumers from adding ad-hoc margin/padding? Absolutely not.

They can do so by using the css prop (or other means from the Style system). This (maybe intention) friction indicates that the user is doing something custom… but their actions are ultimately supported, as their custom styles will still render predictably within the system.

In other words, it’s not as “offensive” as adding a random !important rule in a CSS stylesheet or inline style.

---

With all that being said!!..

As for as system design goes. Maybe the philosophy is…

To allow for maximum flexibility/customization. Within the bounds of the system… Preferred methods are made easier (typically seamless). Custom methods have slightly more friction. The more custom something is, the more friction it has.

[ItsJonQ]

I would say, we should do one method or the other – not both. Either way works for me.

That’s my feeling as well.

Is the prop better than adding it via css?

The only thing I can think of would be that seeing <Card mt={3} /> may look strange to someone not use to it. Whereas margin/padding being added via css (like <Card css="margin-top: 12px" />) is more easily understood.

The downside would be verbosity and the values not using the internal grid system. Whereas with props like mt or px, we can more easily tap those into the grid system (because we know what they are)

The m* and p* patterns aren’t too hard to pickup and learn though. It’s become quite common in CSS Frameworks (as they’re moving towards a more “functional” approach).