Ui Extensions: `<Text/>` vs `<s-text/>` regressions

Extensions
,
1

While working on our React to Preact migration, we’ve hit roadblocks for this component.

React: Text
Preact: s-text

Would it be possible to address the following regressions?:

  • size - The only available size now is small through the type prop. The original size prop is no longer available, can we restore all available sizes lost in this regression?

Checks:

  • Docs, confirm regression.
  • IDE, confirms regression.
  • Trying to implement, confirms regression.

Context:

  • @shopify/ui-extensions-react: 2025.7.3
  • vs
  • @shopify/ui-extensions: 2026.4.0

Thank you very much!

2

Pretty sure its intentional now, as web components identify based on where the s-text is used to set the sizing, based on hierarchy etc.

3

Hey @Luke thanks for reaching back!

I understand that for the s-heading but I’m not sure how does s-text get any context on sizing, the implementation use-cases are infinitely different and it doesn’t follow any hierarchy :thinking:

4

Confirming Luke, this was deliberately dropped.

Inline sizing tends to break visual rhythm at checkout. We’ve determined that size is meant to come from semantics, not a prop. I recommend using tone and type depending on the semantic requirements for each s-text.

5

Thanks for the insight @Paige-Shopify !

We use UI Extensions mainly in the customer accounts, where we expose content-rich features and the ability for merchants to design them with flexibility.

I understand the argument for checkout, but when Customer Accounts can create even isolated Page extensions, would this not make sense there?