Progress Bar Migration#6488
Conversation
* feat(progress-bar): 2nd-gen migration phases 1-4 (setup, API, a11y) Creates the 2nd-gen `<swc-progress-bar>` component through phase 4: - Core: `ProgressBarBase` extending `LinearProgressMixin` with `indeterminate` boolean; types file re-exporting shared linear-progress surface; no variant (single accent fill). - SWC: `ProgressBar` with full `role="progressbar"` render template, determinate value attrs, indeterminate suppression via Lit `nothing`, `aria-labelledby`/`aria-label`/`aria-describedby` wiring, description slot support. - Mixin: replace hard-coded meter docs URL with a computed `docsHref` getter derived from `this.localName` so each concrete component gets an accurate docs link with no per-subclass override. - 1st-gen: `@deprecated` JSDoc on `progress`, `sideLabel`, and `label` string attribute for renamed/replaced APIs. - Migration plan: phases 1-4 checklists updated; B9 (role placement on shadow vs host) flagged for a11y expert review. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix(progress-bar): lint --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
* chore(progress-bar): update reduced motion * style(progress-bar): value changes * style(progress-bar): spacing in storybook * fix(progress-bar): remove meta JSDoc and stories .gitkeep per review
…6456) * chore(progress-bar): storybook, tests and update to migration skill * test(progress-bar): remove duplicate test and target warnings by type/message * test(progress-bar): update with waitFor * fix(progress-bar): address feedback from PR Review
🦋 Changeset detectedLatest commit: 2fb63dc The changes in this PR will be included in the next version bump. This PR includes changesets to release 84 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
📚 Branch Preview Links🔍 Gen1 Visual Regression Test ResultsWhen a visual regression test fails (or has previously failed while working on this branch), its results can be found in the following URLs:
Deployed to Azure Blob Storage: If the changes are expected, update the |
Coverage Report for CI Build 29036112363Coverage decreased (-0.01%) to 96.243%Details
Uncovered Changes
Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
miwha-adobe
changed the title
… into miwhabonini/feat-progress-bar-swc-1769
| **Deferred items are out of scope.** The plan may explicitly defer features to follow-up tickets (e.g. form-associated behavior, cross-root ARIA). Do not implement deferred items in Phase 3 even if they appear in the API section of the plan — mark them as skipped and note the tracking ticket. | ||
|
|
||
| **1st-gen changes are limited to deprecation notices only.** When adding deprecation notices to 1st-gen, restrict changes to: (1) `@deprecated` JSDoc on exported types, consts, and properties; and (2) `window.__swc.warn()` calls added inside already-existing setters or other existing code paths. Do not refactor 1st-gen code structure — no new backing types, no converting simple properties to getter/setter patterns, no new private fields. TypeScript TS6385 hints that arise from deprecated types referencing each other internally are an accepted side effect and do not require structural fixes. | ||
| **For each breaking change in the migration plan, you must add both `@deprecated` JSDoc and a `window.__swc.warn()` call to the 1st-gen file.** JSDoc alone is not enough — types and IDE tooling pick it up, but consumers building against compiled output won't see it. Restrict 1st-gen changes to these two things only: do not add new backing types, do not convert plain properties to getter/setter patterns, do not add new private fields. |
There was a problem hiding this comment.
The previous instructions stated "When adding deprecation notices to 1st-gen, restrict changes to: (1) .....", which was really more just a guardrail in how to add notices, but it wasn't explicit about needing to add the deprecation warning. I didn't find the skill prompts I used (in the migration skill cheat sheet canvas) prompting claude to add the deprecation notice.
| consoleWarnStub.restore(); | ||
| }); | ||
|
|
||
| it('warns in Dev Mode when accessible attributes are not leveraged', async () => { |
There was a problem hiding this comment.
This test is a duplicate in the file, so I removed it
|
|
||
| const spyCall = consoleWarnStub.getCall(0); | ||
| const spyCall = consoleWarnStub | ||
| .getCalls() |
There was a problem hiding this comment.
The tests were breaking because the warnStub no longer has just one warning with the introduction of the additional deprecation warnings.
| * range) or an indeterminate loading animation when completion time is unknown. | ||
| * Implements the WAI-ARIA `progressbar` role on the shadow `.swc-LinearProgress` | ||
| * element (the host carries no ARIA). | ||
| * |
There was a problem hiding this comment.
The a11y analysis requires role="progressbar" on the host, but this puts it on the shadow .swc-LinearProgress element. This is intentional because the host-level ARIA can't aria-labelledby/aria-describedby-reference the shadow-internal label/description ids (Sounds like ElementInternals reference-target not ready). This also matches Meter.
| // ──────────────────── | ||
|
|
||
| const sizeLabels = { | ||
| s: 'Small', |
There was a problem hiding this comment.
@caseyisonit I know you mentioned in this PR as a nit that we should lean on the API values rather than these formatted versions. I checked Meter and it has this same implementation (likely where this was copied from), so if we want to remove these labels, then it should be changed in both files.
| } | ||
|
|
||
| /* Slow rather than stop (WCAG 2.3.3): a static fill loses the indeterminate meaning. */ | ||
| @media (prefers-reduced-motion: reduce) { |
There was a problem hiding this comment.
Considered extracting the reduced-motion overrides (animation-duration: 15s; animation-timing-function: linear) into a shared _lit-styles/ file to be consumed by progress-bar.css, progress-circle.css, and pending-spinner.css (the latter flows into button via its pending state).
Decided to keep it inline for now, but happy to pull it into a shared stylesheet if the team thinks the consistency signal is worth the abstraction. It felt like it might be overkill for two lines. Thoughts?
2 participants
Description
Migrates Progress Bar from Spectrum 1 to Spectrum 2, introducing
<swc-progress-bar>in@adobe/spectrum-wcand adding deprecation notices to the 1st-gen<sp-progress-bar>.2nd-gen component (new):
core/components/progress-bar/—ProgressBar.base.ts,ProgressBar.types.ts, andindex.ts, built on the sharedlinear-progress-mixin.swc/components/progress-bar/—ProgressBar.ts,swc-progress-bar.tsregistration,progress-bar.css, stories, tests,progress-bar.mdxdocs page, and a consumermigration-guide.mdx.API changes from Spectrum 1:
progress→value,side-label→label-position="side",labelattribute →labelnamed slot,--mod-progressbar-*→--swc-linear-progress-*; defaultsizeis now'm'.min-value/max-value,static-color="black",value-label,formatOptions,accessible-label, and adescriptionslot.over-background(usestatic-color="white"), the--mod-progressbar-*custom properties, and host-levelaria-label/role="progressbar"(the role andaria-value*now live on an internal element).1st-gen (
<sp-progress-bar>):@deprecatedJSDoc andwindow.__swc.DEBUGruntime warnings forlabel,side-label, andprogressto guide consumers toward the Spectrum 2 API. Existing tests updated accordingly.Motivation and context
Progress Bar is part of the 1st-gen to 2nd-gen component migration workstream. This delivers the Spectrum 2 implementation with an updated, more accessible API (slot-based labeling, internal ARIA, arbitrary numeric ranges) while giving 1st-gen consumers a clear, warned deprecation path and a dedicated migration guide.
Related issue(s)
Screenshots (if appropriate)
Author's checklist
Reviewer's checklist
patch,minor, ormajorfeaturesManual review test cases
<swc-progress-bar>renders and reflects its APIvalue,min-value/max-value,size,label-position,static-color,value-label, andindeterminatevia controlsvalueclamps withinmin-value/max-value; indeterminate shows the looping animation and ignoresvalue-labelCustom properties apply; internals are not stylable
--swc-linear-progress-fill-color,--swc-linear-progress-track-color,--swc-linear-progress-thicknessto a<swc-progress-bar>--mod-progressbar-*has no effectmigration-guide.mdxto match actual behavior1st-gen deprecation warnings
window.__swc.DEBUGenabled, render<sp-progress-bar label="…" side-label progress="50">label,side-label, andprogress, and no regressions to existing<sp-progress-bar>rendering/behaviorDocs pages render
Device review
Accessibility testing checklist
Keyboard (required)
<swc-progress-bar>alongside other focusable elementsScreen reader (required)
<swc-progress-bar>that has alabelslot (and separately, an indeterminate one usingaccessible-label)role="progressbar"with the accessible name from thelabelslot (oraccessible-label), the current value announced viaaria-valuenow(andaria-valuetext/value-labelwhere set), anddescriptionslot content associated viaaria-describedby; the indeterminate bar announces without a numeric value