fix(hub-ui,json-render-ui): rewire baked Wind3 colors so branding's primaryColor actually retints the UI - #203
Merged
Merged
Conversation
…rimaryColor actually retints the UI Both shadow-root packages compile their utility CSS with Wind3, which bakes theme colors to literal rgb() triplets at build time instead of referencing CSS variables. --devframe-primary (branding's primaryColor) was only ever consumed by the unused --colors-primary-* variables in primary-ramp.css, so overriding it never reached any actual primary/bg-primary/btn-primary utility - the dock, its hover states, and the settings panels stayed the default sage green regardless of branding. Post-process the compiled Wind3 CSS to rewrite each baked primary-ramp triplet into CSS relative-color syntax (rgb(from var(--colors-primary-<stop>, <hex>) r g b / <alpha>)), preserving Wind3's existing opacity mechanics while sourcing the base color from the live variable. Verified end-to-end in Chromium that overriding --devframe-primary now retints text-primary, bg-primary, and btn-primary (including its hover/focus-ring states).
✅ Deploy Preview for devfra ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
…ork's color Each minimal example (Vite, Next.js, Nitro, Rsbuild, Hono) already calls createUi() with no branding, so all five render the identical default sage green dock. Pass branding.primaryColor (and a matching productName) to createUi() in each so the dock visibly reflects the host it's running on - Vite's purple (#646cff), Next.js/Vercel's monochrome black (#000000), Nitro's pink/red (#ff2056), Rsbuild's orange (#ff5e00), and Hono's orange (#e36002). Colors verified against each project's live site (theme-color meta / computed CSS custom properties). hub-vite and hub-next (the two hand-rolled-UI reference hosts) are left on the shared devframe design system, per this repo's parity/one-product design principle for those two. Verified end to end in Chromium (hub-vite-minimal, hub-nitro-minimal) that branding.json is served and --devframe-primary resolves to the configured color inside the dock's shadow root.
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
2 participants
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.
Problem
Branding's
primaryColor(--devframe-primary) didn't affect the actual dock UI — hover states, settings panels, buttons, etc. all stayed the default sage green no matter what was configured.Root cause
@devframes/hub-ui's dock and@devframes/json-render-ui's renderer both compile their shadow-root utility CSS with Wind3 (Wind4's--un-*/:roottheme mechanism doesn't reach a shadow tree). Wind3 resolves theme colors to literal bakedrgb(r g b / alpha)triplets at build time rather than referencing CSS variables.primary-ramp.cssalready derived--colors-primary-*from--devframe-primary, but nothing in the compiled Wind3 output ever read those variables — everytext-primary/bg-primary/btn-primary/ring-primary-*utility (i.e. the whole branded surface) was permanently hardcoded to the default green.Fix
Added
rewireBakedPrimaryColors()indesign/uno.config.ts, run in both packages'scripts/build-css.tsright aftergenerator.generate(...). It rewrites each baked primary-ramp triplet into CSS relative-color syntax:This keeps Wind3's existing opacity mechanics (slash modifiers,
--un-*-opacityvars) intact while sourcing the base color from the live variableprimary-ramp.cssalready derives from--devframe-primary. Also corrected bothprimary-ramp.cssfiles' comments, which inaccurately described a Wind4-only derivation that never actually applied to these Wind3-compiled shadow roots.Verified end-to-end in Chromium that overriding
--devframe-primaryon the shadow host now retintstext-primary,bg-primary, andbtn-primary(default, hover, and focus-ring states). Regenerated both packages'.generated/css.tsbuild artifacts.Dogfooding the fix in the examples
Each
hub-*-minimalexample (Vite, Next.js, Nitro, Rsbuild, Hono) already callscreateUi()with no branding, so all five rendered the identical default sage-green dock. Passedbranding.primaryColor(+ a matchingproductName) tocreateUi()in each, so the dock now visibly reflects the host it's running on:#646cff(Vite purple)<meta name=theme-color>#000000(Next.js/Vercel monochrome)#ff2056(Nitro pink/red)--ui-primary+ hero screenshot#ff5e00(Rsbuild orange)--rp-c-brand#e36002(Hono orange)--vp-c-brand-1hub-viteandhub-next(the two hand-rolled-UI reference hosts) are intentionally left on the shared devframe design system, per this repo's parity/one-product principle for those two.Verified end-to-end in Chromium (hub-vite-minimal, hub-nitro-minimal) that
branding.jsonis served and--devframe-primaryresolves to the configured color inside the dock's shadow root.pnpm lint,pnpm knip,pnpm typecheck,pnpm build(full monorepo), and the fullvitestsuite (1105 tests) all pass.This PR was created with the help of an agent.