Migrate hand-rolled buttons to Web Awesome#51
Open
bramkragten wants to merge 6 commits into
Open
Conversation
Replace every custom <button> element and its per-component CSS with <wa-button> from the @home-assistant/webawesome fork, fulfilling the existing repo convention (contributing.md: prefer <wa-*> components). - Map variants/states: brand/danger + accent/outlined/plain, disabled, and loading (drive refresh uses the native loading prop) - Add ha-svg-icon (ported from the frontend) for inline MDI paths in button slots; icons live in start/end slots instead of custom markup - Extract the toolbox FAB into a fab-button component using wa-tooltip - Map Web Awesome color tokens onto our --ha-* theme colors in styles.css so buttons keep the Home Assistant palette in light and dark - Add vite-env.d.ts for ambient *.css / vite client types Removes ~450 lines of duplicated per-component button styles. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #51 +/- ##
==========================================
- Coverage 89.54% 89.43% -0.11%
==========================================
Files 29 31 +2
Lines 10910 10838 -72
Branches 84 93 +9
==========================================
- Hits 9769 9693 -76
- Misses 1141 1145 +4
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Pull request overview
This PR migrates the frontend wizard UI from hand-rolled <button> elements to Web Awesome’s <wa-button> (using the @home-assistant/webawesome fork), introduces a shared ha-svg-icon for MDI path icons, and adds a reusable floating action button component. It also maps Web Awesome color tokens onto the existing Home Assistant theme variables to preserve the HA palette.
Changes:
- Replace native
<button>usage across multiple views/components with<wa-button>(variants/appearances, disabled/loading). - Add
ha-svg-icon(MDI-path icon renderer) andfab-button(wa-button + tooltip) and wire FAB intoapp-shell. - Switch dependency to
@home-assistant/webawesome, load its default theme CSS, and add Vite client type reference.
Reviewed changes
Copilot reviewed 17 out of 19 changed files in this pull request and generated 14 comments.
Show a summary per file
| File | Description |
|---|---|
| src/vite-env.d.ts | Adds Vite client ambient types reference. |
| src/views/welcome-view.ts | Migrates CTA to <wa-button> and removes bespoke button CSS. |
| src/views/utm/utm-check-view.ts | Migrates UTM actions to <wa-button> and switches icons to ha-svg-icon. |
| src/views/sbc/drive-selection-view.ts | Migrates retry/refresh actions to <wa-button> and attempts to use loading. |
| src/views/sbc/device-selection-view.ts | Migrates retry action to <wa-button>. |
| src/views/path-selection-view.ts | Migrates Back action to <wa-button appearance="plain">. |
| src/views/other-options-view.ts | Migrates Back action to <wa-button appearance="plain">. |
| src/views/minipc/architecture-selection-view.ts | Migrates retry action to <wa-button>. |
| src/views/ha-hardware/device-selection-view.ts | Migrates retry action to <wa-button>. |
| src/styles.css | Adds HA→Web Awesome token mapping (brand/danger/neutral). |
| src/main.ts | Imports Web Awesome default theme CSS. |
| src/components/wizard-shell.ts | Migrates back/cancel/next to <wa-button>, removes bespoke button CSS. |
| src/components/info-dialog.ts | Migrates dialog actions to <wa-button>, removes bespoke button CSS. |
| src/components/confirm-dialog.ts | Migrates dialog actions to <wa-button> (danger confirm), removes bespoke button CSS. |
| src/components/ha-svg-icon.ts | Adds reusable MDI-path icon component. |
| src/components/fab-button.ts | Adds floating action button built on <wa-button> + <wa-tooltip>. |
| src/components/app-shell.ts | Replaces toolbox floating button with <fab-button>. |
| package.json | Replaces @awesome.me/webawesome with @home-assistant/webawesome. |
| package-lock.json | Updates lockfile to match new Web Awesome fork + transitive deps. |
- Retarget unit-test selectors from removed CSS classes (.back-button, .dialog-button.*, .lets-go-button, .footer-button.primary) to wa-button via stable container/attribute selectors; fixes 29 failing tests - Remove dead ?loading binding on the drive refresh buttons (they're never rendered while _loading is true — the view swaps to the spinner) - fab-button: make label optional so ifDefined() actually omits aria-label for icon-only use (empty-string default would have kept aria-label="") - Add unit tests for ha-svg-icon and fab-button - web-test-runner: prefer the "browser" export condition so nanoid (pulled in transitively via wa-tooltip) resolves its browser build instead of the node:crypto one, which failed to import under the test runner Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Migrate all Playwright E2E locators off the removed CSS classes
(.lets-go-button, .back-button, .cancel-button, .footer-button.primary,
.dialog-button.*, .download-button, .refresh-button) to wa-button selectors
- Replace toBeDisabled()/toBeEnabled() with toHaveJSProperty("disabled", …);
Playwright can't read a custom element's disabled state
- Wait for the proxmox configure Next button to enable before clicking (its
node/storage defaults load async; Playwright no longer auto-waits on
wa-button), fixing the proxmox flow specs
- drive-selection: show the full-page spinner only on the initial scan; a
refresh now keeps the list visible and drives the header button's native
loading prop, matching the PR description
- welcome CTA: size="large" -> size="l" (long form deprecated in the fork)
Full chromium E2E suite passes serially (174/174); unit 178/178.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Playwright's isEnabled()/isDisabled() only recognize native/ARIA disabled state, so on a wa-button host they always report enabled. The UTM flow used them to branch (skip/throw) and in one tautological assertion, so the checks were bypassed. Read wa-button's `disabled` JS property directly instead, via a small buttonDisabled() helper. UTM e2e spec passes (42/42 chromium). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
bramkragten
force-pushed
the
webawesome-buttons
branch
from
July 13, 2026 11:27
ad55834 to
8dc235c
Compare
A host aria-label isn't forwarded to wa-button's shadow-root <button>, so the icon-only FAB had no accessible name. Put the label in the button as visually-hidden text (keeping the tooltip) and assert the name in the test. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Web Awesome's dark tokens are gated on a `wa-dark` class, not prefers-color-scheme, so unmapped tokens (neutral hover fill, tooltip colors) stayed light in dark mode. Toggle `wa-dark` on <html> from matchMedia so every Web Awesome component flips correctly, instead of mapping tokens one by one. Our --ha-* overrides still pin brand/danger/surface to Home Assistant colors. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Migrates every hand-rolled
<button>to<wa-button>from the@home-assistant/webawesomefork, fulfilling the existing repo convention (contributing.md: prefer<wa-*>components over custom implementations). First of several scoped Web Awesome PRs from the frontend review in #5 / #16.What changed
wa-buttonacross the wizard shell, dialogs, welcome view, path/other-options views, device/architecture/drive selection views, and the UTM check view. Variants and states are mapped to WA props:brand/danger×accent/outlined/plain, plusdisabledandloading(the drive-refresh button now uses the nativeloadingprop instead of a hand-rolled disabled state).ha-svg-icon— ported from the frontend for rendering inline MDI paths. Icons now live inwa-button'sstart/endslots (with automatic spacing) instead of custom markup; the arrow/refresh/back glyphs use it too.fab-button— the floating "Open Home Toolbox" button is extracted into its own component built onwa-button+wa-tooltip.--ha-*theme colors instyles.css, so buttons keep the Home Assistant palette (primary#03a9f4, danger#db4437, neutral text) in both light and dark mode.@home-assistant/webawesomefork (same version as the frontend) and addsvite-env.d.tsfor ambient*.css/ Vite client types.Net result removes ~450 lines of duplicated per-component button CSS.
Testing
tsc,eslint, andvite buildall pass.Follow-ups (out of scope)
option-card,device-card,drive-card, mini-PC setup-method) →wa-card*-success-viewand the↗/→glyphs inside those cards--wa-color-*token map (only button-consumed tokens are mapped here) once more WA components (inputs, dialogs, etc.) are adopted🤖 Generated with Claude Code