[Layout] Default spacing

[aveline]

Currently we include some default spacing values in the Layout components. Is this something we should do or should we remove all default spacing values?

We have touched on this discussion before, so here is a summary of some of the points that have been brought up.

Having zero as the default encourages me to think about the spacing I need and forces me to make intentional decisions for my design. Having a default value provided… I start questioning do all layout components have the same default spacing? What is this value? Is the default value responsive? Is this documented? Can I autocomplete to it to the value and use it by accident? I don’t think we should provide a default value as layout requires intentional decisions. @alex-page

I'm firmly in the camp that none of our components should come with default values which affect the positioning of the element within its parent, so the particular case is trivial: don't have defaults. See: Margin considered harmful [link] @jesstelford

When we first decided to remove them it was before we had started on layout components. We decided to be opinionated with these components in adding default spacing values (also received positive feedback in usability testing for applying defaults). When the issue was brought up again after some of the layout work had been done it seemed like there wasn’t a strong consensus for keeping or removing them
I find the defaults familiar after using them for a while. So many times when coding in web I’d add a card and content etc… only to go to the browser and see no padding, going back to code and adding the sectioned prop. That sort of thing bugged me because all cards have the same padding @kyledurand

Right now my hunch is more low level components, like Box or Bleed [shouldn't] have a default. They have the most flexibility and are probably used for more varied purposes and so it's harder to land on sensible default. And more opinionated components like Card have defaults or even baked in opinions. They offer less flexibility and if they don't suit the use case, then they can be substituted with the more flexible components. Ex. Box [link] @aveline

[alex-page]

Default spacing zero

• Similar to CSS. If there is no margin, gap, padding property then there isn't any spacing added.
• React props added correlates to CSS code added
• Understandable without reading documentation
  • <Inline>...</Inline> has no spacing
  • <Inline gap="2">...</Inline> has a gap of 2
• All primitive components have the default of zero and it's faster to learn multiple parts of the system
• All spacing is added with intention by the developers and designers. There isn't a perfect default spacing for many components.
• Documentation is not necessary for learning what the default spacing value is (it's zero)
• Cannot accidentally use the same value as the default as no spacing = no property

I would like to see Box Inline Stack Bleed Columns by default have no spacing unless added intentionally.

[heyjoethomas]

I think the distinction here between lowest level primitives and higher level components like Card is spot on. Primitives should remain totally flexible and I think not providing defaults is the way to do this. Higher order components can then have opinions like default spacing/padding because they are rendering more opinionated UI be nature.

[SeanyB]

My thoughts regarding @kyledurand's point on the DX preference for default values for Card, it does seem preferred to have an style and default value opinion in the case of Card. Though, Card could be categorized as a presentational component rather than layout component. The layout components don't include visual styles rather only "invisible" spacing, size, and alignment properties.
Having a default of zero spacing for layout components Box, Inline, Stack, Bleed, and Columns seems even more natural if we can exclude Card as part of the layout component categorization.

I agree with these points. A Card isn't just layout, it's presentational. If a Card has zero padding, then it also won't show rounded corners. I think it would be a very strange DX if the default behaviour whenever a Card is added to a page is that it looks identical to a Box.

[aaronccasanova]

Agree with every bullet point and everyones feedback thus far. Also, I don't believe we can confidently set a sensible default for spacing on primitive layout components since that aspect is so dependent on the design being created. The idea of setting default spacing to speed up development assumes a given design matches the default (otherwise, were kind of back to where we started).

[sophschneider]

+1 to no default for primitives, defaults for presentational. Primitive layout being Box, Inline, Stack, Bleed, Columns.

[jesstelford]

+1 all of this, with one clarification: Layout components (Box Inline Stack Bleed Columns) should have default of 0.

ie; All spacing props should be optional, and if the prop is not set, the value is set to 0;

const Stack = ({ gap = 0, ...props }) => { /* ... */ }

[kyledurand]

A couple of thoughts

Default spacing 0 pros

• Easily understandable in consuming projects (love this)

Default spacing 0 cons

• Users always have to add spacing (What spacing do I use? Tokens won't always match up to Figma so have to refer to Polaris token or component docs)

Sensible default value pros

• Historically we've applied spacing gaps to our layout components, it's familiar to Shopify.
• Content almost never butts up against eachother in a stack or in columnss. We'll rarely see these components used without gap spacing.
• Components work together nicely (Bleed cancels out default card padding)

I can see benefits from both sides here and we have spoken about removing spacing defaults in the past, not just for one off components but all of them, especially when talking about removing 0 values from tokens.

My strongest point for keeping the defaults is this: If I were the user they'd help me build faster and have confidence that most of the time they're going to be right.

[alex-page]

These are some awesome points. Definitely agree about the historical usage at Shopify. I also agree that it would make it much faster to build out most UI's if there was some spacing as 99% of the time there will be a space added.

I think this clashes with building infrastructure/primitive ui's though. They should have as small as a surface for opinions and be scaled into opinions by composition.

[jffortier]

Hey folks!

I thought I’d share our perspective in Checkout UI Extensions and hopefully contribute to the discussion that could lead to alignment and simplify the shared UI-Extensions components API project coming soon.

In Checkout, for low-level components, we consider properties like spacing, padding, border, background etc, as solely additive properties. This includes spacing in the layout primitives. This is in line with what I believe the Polaris team has landed in this discussion.

We do have 2 outliers that contradicts this pattern, but we’ll be correcting them in the upcoming cycles. The BlockStack and InlineStack component (equivalent to your Inline and Stack) currently have a default spacing between its children. The main reason is for developer ergonomics. These components are the most basic way to lay out elements and they are used very often in our apps (to space boxes, block of text, icons, tags, textfield, etc. ). The rationale to include default spacing was to improve the experience of writing the majority of the use cases. Spacing is almost always needed. Make the most common UI easy, and the rest possible kinda thinking. In retrospect, I believe it was a mistake and we’ll be aligning the spacing prop with other components props (ie: no default, additive only) for similar reasons that were shared in this discussion.

Boolean type

For the Modal component we released to 3rd party devs recently, we introduced a new concept that gets us similar benefits as default values, without the default values already set🤪. Modal has no default padding, but developers can set the padding property to true (<Modal padding>) and get our preferred padding for modals. The boolean is in addition to the named values that maps to a spacing scale. This offers a couple benefits we really like for Modal but also applies to other properties and components:


• offers a quick and easy way for developers to set a padding
• the ability for the library to assign a preferred value (this value could be different for each component and match the most common use case, if any).
• helps minimize inconsistency between all modals used in an app. A developer does not need to look at docs or other instances of Modal in the app to make sure it’s consistent and respect the design
• allows us to offer smart defaults for every screen sizes. Modal in default Checkout is designed to have less padding on small screens than large screens. It’s a subtle change, but we believe it’s important. Without the boolean, we doubt every developer using the Modal would consider changing the padding base on viewport. This would also be tedious for them to match the values previously used in the app.

We believe this pattern could also apply to the spacing properties of layout primitive. For example, an author could say:

• "I want to add default spacing between these text blocks". This would be written like this:

<BlockStack spacing>
   <TextBlock>paragraph 1</TextBlock>
   <TextBlock>paragraph 2</TextBlock>
   <TextBlock>paragraph 3</TextBlock>
   <TextBlock>paragraph 4</TextBlock>
</BlockStack>

• "I want a box with a border, some padding and default corner radius". This would be written like this:

<View cornerRadius border padding>

   content
</View>

This is not yet implemented in our components (only Modal so far), but we’re quite happy with the potentials. Would that be a pattern Polaris (or I guess Admin Extensions UI components) would consider for a shared API down the line? Any thoughts?

Thanks y’all!

[jffortier]

I like the boolean approach

Can't take any credits, it was @lemonmade idea.

[joeyfreund]

I also really like the boolean approach.
One thing though - I would consider using the name padded instead of padding.

• padded communicates better that it's a boolean property
• padding is a very familiar name for a property that is not boolean

[alex-page]

My understanding was that the property can be a bool or string so you can do padding or padding="1". padding by itself would provide the default value and set the value to true.

[joeyfreund]

Thanks for the clarification, @alex-page.

[jffortier]

Exactly. The padding property for a button could be typed like this:

type SpacingScale = "1" | "2" | "3" | "4" | "5" | etc.

interface Button {
  padding?: boolean | SpacingScale;
}