See all services → Shopify Plus Partner
Polaris Developer

Upgrade Embedded Apps to Stable Polaris CDN 1.1

Polaris Web Components 1.1 is now stable and rolls out automatically to apps on the standard CDN URLs. Overlay events no longer bubble and DatePicker stops double firing, so audit embedded admin tooling.

Executive summary

What changed

Polaris Web Components is the UI layer for apps embedded in the Shopify admin. Version 1.1 now serves from the stable channel URLs, and because the CDN follows semantic versioning, anything loading polaris.js or polaris-1.js receives it without a deploy.

Three components are new. EmptyState covers empty lists, tables, and pages, rendering as a full width message beneath the headers inside a TableBody. Number renders inline numeric text with tabular figures so columns align. Progress shows task advancement.

New properties arrive too: fontSize on Heading, Paragraph, and Text, visibleMonths on DatePicker accepting auto, 1, or 2, and supplementalStart on Page for content ahead of the main body.

The fix list is the substantial part. Overlay show, hide, aftershow, afterhide, and aftertoggle events no longer bubble, worth reading closely if you listen for them on an ancestor. Modals no longer dismiss when a click or drag crosses the modal edge. DatePicker no longer fires a duplicate input and change event when the same value is set back onto it, exactly what controlled React components do after a selection, so onChange runs once. Popover, Menu, Tooltip, Select, NumberField, TextArea, DateField, and ColorPicker received positioning, focus, or parsing fixes, and fontVariantNumeric is deprecated in favour of Number.

Why it matters

For most Plus merchants this is invisible, and that is the point. It lands in the admin apps your team already uses, not the storefront, and requires nothing from you.

It matters where you own custom admin tooling. Plus merchants routinely run bespoke embedded apps for order triage, purchase order entry, or an ERP sync console, and those inherit 1.1 automatically. Two behaviours could differ from what your code expects: a handler listening for overlay events on a parent element goes quiet, and a form that double submitted on date selection stops. The second is a fix you want. The first is a regression if you relied on bubbling.

The DatePicker fix is quietly valuable for delivery date capture or B2B ship date entry, where double firing produced duplicate validation calls and occasionally duplicate draft orders. Any debounce you carried for it can go. Teams weighing whether to build this tooling in house should read our view on custom Shopify apps for enterprise stores.

Role-specific impact

Use-case example

Real-world scenario

A Plus merchant runs an internal embedded app where service staff schedule delivery dates on B2B orders. Because DatePicker fired change twice per selection, the app issued two validation requests per date and occasionally wrote two draft order updates under load. The team patched it with a 300ms debounce. After 1.1 the duplicate event is gone, the debounce comes out, and the interaction is responsive again. Across roughly 900 scheduled orders per week that halves validation call volume and removes a class of duplicate write.

Implementation checklist

  1. Confirm which CDN URL your embedded apps load. If it is polaris.js or polaris-1.js, you are on 1.1.
  2. Search for listeners on show, hide, aftershow, afterhide, and aftertoggle attached to anything other than the overlay itself.
  3. Rebind those to the overlay or the equivalent on* property, then retest modal and popover flows.
  4. Remove deduplication workarounds added for duplicate DatePicker events and verify onChange runs once.
  5. Replace fontVariantNumeric on Text and Paragraph with the Number component before it is removed.
  6. Pin to 1.1 only if you have a reason to freeze. Pinning defers work rather than avoiding it.

FAQ

Q: Do we need to deploy anything to get 1.1?

A: No. Apps on the stable channel URLs receive it automatically. A deploy is only needed if you change code in response to the overlay event or DatePicker behaviour changes.

Q: Does this affect our storefront or checkout?

A: No. Polaris Web Components render admin interfaces only. Theme code and checkout UI extensions are unaffected.

Resources

App Home documentation

Need guidance? Talk to Makro.