Executive summary
- What: Polaris Web Components 1.1 is now on the stable CDN channels, adding EmptyState, Number, and Progress plus a long list of overlay and form fixes.
- Why: It is the first minor release under the CDN's semantic versioning model, so apps on polaris.js or polaris-1.js pick it up automatically.
- Who: Teams building or maintaining embedded Shopify admin apps, including the custom internal apps many Plus merchants run.
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
- Marketers: No direct impact. Admin tools your team built may look marginally more polished, with better empty states and aligned numeric columns in reports.
- Developers: Audit any listener attached to overlay events on an ancestor, since those events no longer bubble. Move them onto the overlay or use the matching on* properties, then check for DatePicker debounce workarounds that are now redundant.
- Store admins: Expect small visual changes in embedded apps, notably clearer empty tables and modals that no longer close when a drag ends just outside them.
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
- Confirm which CDN URL your embedded apps load. If it is polaris.js or polaris-1.js, you are on 1.1.
- Search for listeners on show, hide, aftershow, afterhide, and aftertoggle attached to anything other than the overlay itself.
- Rebind those to the overlay or the equivalent on* property, then retest modal and popover flows.
- Remove deduplication workarounds added for duplicate DatePicker events and verify onChange runs once.
- Replace fontVariantNumeric on Text and Paragraph with the Number component before it is removed.
- 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
Need guidance? Talk to Makro.