[Checkout UI] Banner Component Enhancements

[aubreytayloracn]

Please list the related package(s)

• checkout-ui-extensions

Describe the changes you are looking for

Enable more granular control over the Banner component title sizing, spacing, and padding.

Layout components like, BlockStack/Layout; InlineStack/Layout, expose props to control spacing and padding and text components expose props for size.

Alternatively, allow Banner to work more like Disclosure and set it's own child elements and collapsible functionality.

Describe alternatives you’ve considered

Using child elements

The Banner supports child elements, which is great but this methodology opts us out of the collapsible functionality. Unfortunately, in my use case, losing out on collapsible is not a viable work around.

Recreating a banner with lower-order components

You can almost re-create the banner using a Disclosure element + some additional wrapper and layout components. Unfortunately, however, you cannot replicate the "appearance" functionality the banner comes with on a generic View (or any other layout component it seems). The closest I could get was a "subdued" background and a "medium" borderWidth.

Additional context

Unfortunately, the Banner component does not surface props like this which make it difficult to control it's appearance, especially in targets with limited real estate like purchase.checkout.cart-line-item.render-after (this is especially bad on mobile checkout for this target in particular).

I think exposing props / settings like:

• titleSize: Set size of text specified for title prop
• padding: Set component padding
• spacing: Set component spacing

Would be add some nice flexibility to this component and remain inline with the overall Checkout UI philosophy.

Screenshots

• A lot of wasted real estate even on desktop.

• Looking particularly rough on mobile. Would be nice to have the option to tighten this up.

[nrthbound]

This is a bigger issue with the components and their lack of configuration. No padding, margin, colors, CSS. They took everything we knew about HTML5/CSS3 and threw it all out the window. I still have no idea how these components got so bad.

[aubreytayloracn]

@nrthbound The philosophy of keeping things locked down make sense if the objective is to keep checkouts consistent and performant.

If I had my druthers, I would ask that all components inherit a common set of props like spacing, padding, appearance, etc. For higher-order components, like the Banner, it would be nice if at least I could rebuild that component from lower order components for more control.

[nrthbound]

@nrthbound The philosophy of keeping things locked down make sense if the objective is to keep checkouts consistent and performant.

If I had my druthers, I would ask that all components inherit a common set of props like spacing, padding, appearance, etc. For higher-order components, like the Banner, it would be nice if at least I could rebuild that component from lower order components for more control.

That's fair. I'd be happy with that. I'd still prefer some support for coloring my extensions.

[gil--]

The problem is how do you expose the props/configuration you're suggesting without breaking checkout across different surfaces? I feel like asking for specific spacing/margins/colors is thinking about checkout solely as a single surface on web rather than across the growing number of different surfaces (3+). It's practically impossible so that's why there's a common inheritance pattern with limited spacing and coloring (box has bg prop).

[nrthbound]

How do you mean? All checkout does now with the current components available to us is export to HTML/CSS. It's not using any technology that doesn't already support the previous ask. They also already support padding on some components and they do it the same way it's done normally, except all they did was change the language which just makes it more convoluted and complicated. base, loose, tight, extraLoose, extraTight are just preset CSS variables. And just like in a css class, you can do all sides, left and right, or just top and bottom.

They could have easily implemented something like Tailwind to handle a lot of this, which would ensure an easier developer transition without basically taking all of the building blocks we're used to in HTML/CSS and renaming them and making their functionality more convoluted. We have 6 brands, and some of those brands have several stores and they've all seen a decline in conversion since moving to the new Checkout. However, since it's so limited in what we can do with it, and we're being forced on it anyway, what's our solution?