When using the Divider component in Shopify UI Extensions with different size variants, only the size="small" variant renders correctly. All other size variants (base, large, extraLarge) appear to have 0px height and are effectively invisible.
All divider variants should render with their respective heights:
size="small" - Thin divider line
size="base" - Default/medium divider line
size="large" - Thicker divider line
size="extraLarge" - Thickest divider line
Actual Behavior
size="small" renders correctly
size="base" has 0px height (invisible)
size="large" has 0px height (invisible)
size="extraLarge" has 0px height (invisible)
Investigation
The issue appears to be missing CSS styles for the larger divider variants. When inspecting the DOM, the divider elements are present but lack the proper height/styling that would make them visible.
Environment
Extension Type: Customer Account UI Extension
Package: @shopify/ui-extensions-react
Component: Divider
Context: All customer account extension surfaces
Impact
This bug prevents proper visual separation in UI extensions, forcing developers to either:
Use only the small variant (limiting design options)
Implement custom divider solutions (inconsistent with Shopify’s design system)
Use workarounds like empty View components with border styles
Request
Please investigate and fix the missing styles for Divider size variants base, large, and extraLarge in UI Extensions. This should be a straightforward CSS fix to ensure all documented size variants work as expected.
Having consistent divider styling is essential for building professional-looking extensions that align with Shopify’s design system.
Hey @muchisx , thanks for flagging this and for the repro example code there. Are you seeing this happen in all types of UI extensions? Just want to confirm where you’re seeing this pop up so that I can replicate correctly and reach out to some folks internally on my end here.
Thanks for confirming @muchisx and no worries. I’ll try to replicate the issue on my end here and reach out internally to investigate further. I’ll loop back with you here once I have more info on our end to share
Just want to confirm if this is what you’re seeing since I think I was able to replicate this on my end. Once I hear back from you, I’ll get in touch with our product team so we can look into this further.
Thanks @muchisx, no worries, appreciate you confirming here as well (just wasn’t sure if I was seeing the same error, good to know I was!), I’ll get in touch with our product team for you right away now and be back in touch once I have more to share
Hey @muchisx - quick update! We’ve identified the issue on our end and are working on a fix. I’ll loop back with you here once I can confirm it’s been made live on our end.
@muchisx - thanks for the ping! We’re taking a look at this, I’ll loop back with you once I can confirm the next steps. Really appreciate your patience
@muchisx - following up here again , we’ve resolved the issue on Checkout targets, but are still working on the fix for Customer Account targets, this should be resolved soon there as well. Ican’t provide an exact timeline, but I’ll ping you here in this thread once the fix is live
Hey again @muchisx - just confirming the fix should now be live for Customer Account UI extensions as well. Let me know if you still see the issue and I’d be more than happy to keep looking into this.
Hey @muchisx , thanks for sharing the elements tab there. For the extra large divider size, our docs have it formatted like this: extraLarge. Can you try that formatting and let me know if the issue persists? If so, I’m definitely happy to work on this internally. Hope this helps!
Thanks for clarifying @muchisx, understood! I’ll do some further digging into this on my end and loop back with you here once I have an answer/next steps for you.
Hey @muchisx - following up here again . Can confirm that extraLarge mapping to Large is expected behaviour at the moment. I can’t guarantee when this will be reflected in the docs, but I’ve passed some feedback along to have this be fixed in the documentation as well.
Let me know if I can clarify anything more on our end here as always