Access to internal admin web components

Polaris
1

Could we please get some transparency on when we’ll get access to components that the Shopify admin uses but we don’t get access to?

For example <s-internal-date-picker viewtype="multiple"> which is used in the Analytics page date range picker.

There are many more too…

3

Would be nice to hear something from Shopify on this…

4

You can technically already use them if you just use that internal file, but they are entirely undocumented and many have huge holes in functionality compared to the public versions.

The s-internal-press-button for example has many regular s-button features missing, but has a pressed state

5

Hi Luke, I’ll check internally if it’s possible to release a roadmap or similar and get back to you.

6

I was able to confirm that it’s being considered. We’re not able to share any other details at this time, so I’d recommend keeping an eye on the developer changelog.

7

Hi @Luke, following up here. As part of the Polaris CDN’s adoption of semantic versioning, upcoming changes, including new components, will be available to test through release candidate builds before they reach stable channels.

8

Appreciate the update Paige, thank you!

Are you able to give any insight on if this is dog fooded at all? For example, the recently released new collection page uses mostly Polaris React w/ some s-internal components and very few, if any actual Polaris Web Components which makes it extremely hard for us to reliably replicate official areas of the admin within our apps unless we still used React Polaris (which we’ve been told to not do) or recreate all of the s-internal components ourself

10

Heya, couple of things here:

  • Everyone, including internal teams, is encouraged to use Polaris web components. Everyone has a choice in the matter, but staying on the mainstream components will help keep you in-sync with future updates
  • We dogfood the s-internal components with properties and slots that will eventually roll out to the 3P CDN. We’re fast/quick with potential breaking changes internally since we fully control the code there (and can manually migrate if necessary); what sticks around is an API we’re happy with, and can more confidently ship to you all without you needing to do breaking changes as frequently. So in a way, you can inspect the s-internal components and “preview” what’s coming to you soon.

As Paige mentioned above, we’ve been working things behind the scenes in order to roll this out, and one of those is the versioning release.

Thanks.