[Layout] Responsive props

[kyledurand]

Let's discuss a couple options for setting responsive values in our layout components. In some cases it feels like over engineering to allow values to each of our 5 breakpoints.

Take padding for instance:
padding={{xs: '1', sm: '2', md: '3', lg: '4', xl: '5'}}. This creates five custom properties that render every time this Box renders. It also relies on breakpoints added in css:

--pc-box-padding-xs: var(--p-space-4);
--pc-box-padding-sm: var(--pc-box-padding-xs);
--pc-box-padding-md: var(--pc-box-padding-sm);
--pc-box-padding-lg: var(--pc-box-padding-md);
--pc-box-padding-xl: var(--pc-box-padding-lg);

padding: var(--pc-box-padding-xs);

@media #{$p-breakpoints-sm-up} {
  padding: var(--pc-box-padding-sm);
}

@media #{$p-breakpoints-md-up} {
  padding: var(--pc-box-padding-md);
}

@media #{$p-breakpoints-lg-up} {
  padding: var(--pc-box-padding-lg);
}

@media #{$p-breakpoints-xl-up} {
  padding: var(--pc-box-padding-xl);
}

This is a lot of overhead for something as simple as padding. How often are we or our consumers going to need different values at each of these breakpoints?

Alternative solution:

Use our breakpoint utility function:

  const {smUp, mdUp, lgUp, xlUp} = useBreakpoints();

  const padding = () => {
    switch (true) {
      case xlUp:
        return '5';
      case lgUp:
        return '4';
      case mdUp:
        return '3';
      case smUp:
        return '2';
      default:
        return '1';
    }
  };
  return (
    <Box padding={padding()}>
  );

This is an extreme example where the consumer needs different values at each breakpoint where 99% of the time it would probably look more like this:

<Box padding={mdUp ? '2' : '1'} />

Because layouts in the admin don't usually change padding at more than one breakpoint.

There are drawbacks to each option here. One major one would be how difficult migrations would be where we'd have to import useBreakpoints and figure out the logic vs managing the props manually.

I think the responsive props object is generally clearer but it does add a lot of overhead

[aveline]

@aaronccasanova and I jammed on this

@mixin responsive-props($componentName, $componentProp, $declartionProp) {
  --pc-#{$componentName}-#{$componentProp}-xs: initial;
  --pc-#{$componentName}-#{$componentProp}-sm: var(--pc-#{$componentName}-#{$componentProp}-xs);
  --pc-#{$componentName}-#{$componentProp}-md: var(--pc-#{$componentName}-#{$componentProp}-sm);
  --pc-#{$componentName}-#{$componentProp}-lg: var(--pc-#{$componentName}-#{$componentProp}-md);
  --pc-#{$componentName}-#{$componentProp}-xl: var(--pc-#{$componentName}-#{$componentProp}-lg);
  #{$declartionProp}: var(--pc-#{$componentName}-#{$componentProp}-xs);

  @media #{$p-breakpoints-sm-up} {
    #{$declartionProp}: var(--pc-#{$componentName}-#{$componentProp}-sm);
  }

  @media #{$p-breakpoints-md-up} {
    #{$declartionProp}: var(--pc-#{$componentName}-#{$componentProp}-md);
  }

  @media #{$p-breakpoints-lg-up} {
    #{$declartionProp}: var(--pc-#{$componentName}-#{$componentProp}-lg);
  }

  @media #{$p-breakpoints-xl-up} {
    #{$declartionProp}: var(--pc-#{$componentName}-#{$componentProp}-xl);
  }
}

.AlphaStack {
  @include responsive-props(stack, spacing, gap);
  [...]
}

We want to avoid using the useBreakpoints() as it's intended as more of an escape hatch. Better to handle the responsiveness in css.

So we can see us having a set of utilities including this @mixin responsive-props, getResponsiveProps(), and type ResponsiveProp. Curious to hear your thoughts!

[laurkim]

Is there more context for why useBreakpoints() is intended as an escape hatch @aveline? I think the caveat of having an approach like the responsive-props mixin is that it would result in a failing line in the coverage dashboard, i.e. (ActionList.scss). Whereas using useBreakpoints() in the component doesn't result in failures (i.e., AlphaCard.tsx).

[aaronccasanova]

I think the caveat of having an approach like the responsive-props mixin is that it would result in a failing line in the coverage dashboard

Note: Mixins only count as coverage failures if they are included in the stylelint-polaris/at-rule-disallowed-list

[aveline]

I don't think we would want to expose those mixins externally either.

@lemonmade gave some good context why we should use useBreakpoints() sparingly. It also interferes with SSR and SSR of any child components of a component that is using it.

[lemonmade]

IMO, it would be great to avoid a solution that requires responsive conditions to be resolved in JavaScript, like the useBreakpoints() hook described here. Doing this in JS is problematic for a few reasons:

• JavaScript needs to execute before responsive layouts can be shown
• To make this work for UI extensions, we'd need to forward screen size information into the sandboxed environment, and re-implement logic on when breakpoints match, since those sandboxes can't synchronously evaluate media queries like you can on the main thread

[kyledurand]

Thanks folks! Going to close this with the consensus that css approaches are better for everyone here. We're going to update some APIs to allow responsive props as well as single values