[Feature Request] <s-progress> on App Home

Hi everyone!

I’d like to make a feature request: bringing the <s-progress> component from Checkout to the App Home, with one small detail: including the same tones and sizes available in the React version. This is one of the last Polaris React components that still needs to be replaced in order to finish the migration to Polaris Web Components.

Thank you!

image

Hey @devfabri :waving_hand: - thanks for reaching out.

Just confirming on our end that <s-progress> isn’t available on App Home right now - the Checkout and Customer Account versions exist, but App Home’s status indicators are currently limited to Badge, Banner, Spinner, and Empty state. I’m happy to pass this along for you though

Just a few quick things that would help with escalating this up - which tones and sizes are you actually relying on from the React ProgressBar? The Checkout version only supports tone="auto" | "critical" with no size prop, so if you only need one or two variants that’s a much smaller ask than full parity. Also, are you building on the embedded App Home surface or the App Home UI Extension surface? And since you mentioned this is one of the last components blocking your migration, what else is still on Polaris React for you?

In the meantime, keeping the Polaris React ProgressBar alongside your web components should be fine as an interim - not super ideal, but it shouldn’t block the rest of the migration.

Hope to hear from you soon.

Hi @Alan_G! Thanks so much for getting back to me!

To give you some context, I am building on the embedded App Home surface.

Regarding the ProgressBar: at least in my case, all instances are using the size="small" prop. As for the tones, the essential ones for my use case would be "primary", "critical", and "success", as clear visual feedback is very important for merchants.

Regarding other things blocking the migration: prior to the v1.1 release, one of the most glaring issues preventing a full migration was the inability to manually choose font size and weight, since not every intention can be adequately conveyed with just a regular 13px font. So, I’m really happy with what’s coming in the new version!

Speaking specifically about missing components, the Combobox is really needed for creating autocompletes. I know the s-popover component exists today, but as far as I know, it cannot be triggered by an s-text-field.

For now, I’ve been keeping the React versions for the things I’m missing. However, in terms of code quality and maintenance, it’s not ideal. For me, the faster I can move away from a deprecated library, the better.

Thanks in advance!

P.S. AI was used only to assist with the English translation of this message.

Hey @devfabri - thanks for the detail, that’s exactly what I needed.

Just confirming on our end that I’ve passed both along internally here. - the <s-progress> ask with size="small" and primary/critical/success tones, and the Combobox gap. I don’t have a timeline to share, but just wanted to let you know I’ve passed this along.

On Combobox specifically - you’re right that s-text-field can’t trigger s-popover directly. There’s a thread here where another dev got partway by wrapping an s-search-field in an s-clickable with commandFor pointing at the popover. It works for basic cases, but keyboard navigation through the options isn’t there, so not super ideal if a11y matters for your use case. Keeping the React Combobox for now is a reasonable call.

Glad the fontSize work in 1.1 lands for you. Let me know if I can help out further.