Executive summary
- Polaris Web Components 1.1 is available as a release candidate at a dedicated testing URL, ahead of a stable release.
- It adds two components and three properties, and corrects a long list of overlay, date picker, and form defects. Two of those corrections change existing behaviour.
- Teams maintaining embedded admin apps should test now. Nothing reaches production until the stable build ships.
What changed
Shopify published a release candidate build of Polaris Web Components 1.1, loaded from a URL that updates in place while the minor is finalised. Two components are new. EmptyState covers empty lists, tables, and pages, and renders as a full-width message beneath the headers when placed inside a table body. Number renders inline numeric text with tabular figures, so columns of figures line up.
Three properties are new: fontSize on Heading, Paragraph, and Text, which sets text size directly; visibleMonths on DatePicker, accepting auto, 1, or 2; and supplementalStart on Page, for content placed before the main page content. The fix list is considerably longer than the feature list. Overlay show, hide, aftershow, afterhide, and aftertoggle events no longer bubble, matching the behaviour of toggle. Modal no longer dismisses when a click or drag crosses its edge, and focus return and heading overflow are fixed. Popover and Menu positioning, overflow scrolling, resize-after-open, and delayed hiding in Safari are corrected, along with Escape closing an enclosing modal. DatePicker weekday headings and screen reader announcements are fixed across locales, and setting the same value back onto the picker no longer fires a second input and change event.
Why it matters
Two of these carry the label of bug fixes but are behaviour changes, and both can quietly alter how an existing app works. Non-bubbling overlay events will break any handler attached to a parent element rather than to the overlay itself. The DatePicker deduplication halves the number of change events in controlled React forms, which is correct, but any code tuned around the double fire, including analytics counters, autosave triggers, and debounce logic, now behaves differently. Surfacing that during a release candidate window is precisely the point of having one.
The remainder is straightforward quality work, and it lands where it is felt. Accidental modal dismissal and lost form state are among the most common complaints from operations staff working in custom admin tooling, and both are addressed here.
Role-specific impact
- Marketers: no direct action. Expect fewer lost entries and misplaced tooltips in the internal tools used for merchandising and campaign setup.
- Developers: point a staging build at the release candidate URL and exercise every overlay, date picker, and form. Audit for overlay event listeners bound to parent elements.
- Store admins: report anything that looks or behaves differently during the test window. Feedback given now is far cheaper than a defect found after the stable release.
Use-case example
Real-world scenario
A B2B merchant runs a custom quoting app inside the Shopify admin, where sales reps set a valid-until date and a price list on each quote. The date field is a controlled React component, so every selection currently fires a change event twice, which the team absorbed with a debounce. Under 1.1 the duplicate event disappears, so the debounce becomes dead weight and any per-change autosave halves its write volume. Verifying that on staging takes an afternoon. Discovering it after the stable release, on an app producing roughly 400 quotes a week, costs considerably more.
Implementation checklist
- Point one staging environment at the 1.1 release candidate URL. Never production, since the bundle updates in place.
- Search the codebase for listeners on show, hide, aftershow, afterhide, and aftertoggle, and move any bound to parent elements onto the overlay.
- Retest every modal, popover, menu, and tooltip, including Safari and narrow viewports.
- Verify controlled DatePicker fields and remove workarounds built around the duplicate change event.
- Evaluate EmptyState and Number as replacements for custom markup you are currently maintaining.
- Record the results and schedule the move to the stable 1.1 URL once it publishes.
FAQ
Q: Can we run the release candidate in production?
A: No. The release candidate URL updates in place as changes accumulate during the window, so the bundle underneath your app can change without notice. Use it in development and staging only.
Q: What happens when 1.1 becomes stable?
A: A pinned polaris-1.1.js URL is published at that point, and the stable channel picks the release up automatically. As a minor, it should not break anything, but the two behaviour corrections above are worth testing before it arrives.
Resources
Polaris 1.1 web components reference
Need guidance? Talk to Makro.