feat(core): color a dock-bar entry's badge via a new badgeVariant field - #528
Open
dvcolomban wants to merge 2 commits into
Open
feat(core): color a dock-bar entry's badge via a new badgeVariant field#528dvcolomban wants to merge 2 commits into
dvcolomban wants to merge 2 commits into
Conversation
DockEntry's badge has always been a plain count with a fixed gray fill — no way to distinguish, at a glance, "this count is provisional" from "this is the settled value". json-render's own Tabs component already solved this one level down (TabDescriptor.badgeVariant, with a real variant→color map); this carries that same variant set up to the dock-bar entry itself. badgeVariant is declared via the existing DevframeDockEntryRegistry declaration-merge pattern this package already uses, staying optional so every existing badge consumer keeps its current look unchanged. DockEntry.vue falls back to its pre-existing bg-gray-6/text-white classes at 'default'/ unset, and only switches to an inline-styled fill (reusing Tabs.ts's own colors map) for a non-default variant.
@vitejs/devtools
@vitejs/devtools-kit
@vitejs/devtools-oxc
@vitejs/devtools-rolldown
@vitejs/devtools-vite
@vitejs/devtools-vitest
commit: |
…ents The tab-badge fill (colors[variant].bg, alpha 0.15) read as too faint reused on the dock bar — boosted via CSS relative-color syntax instead of adding a second color table.
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
1 participant
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.
Why
DockEntry's badge is a plain string label with a fixed gray fill — no way to color it. json-render's ownTabscomponent already supports this one level down (TabDescriptor.badgeVariant, with a real variant→color map, used today by tab strips inside a dock's own content); the dock-bar entry itself has no equivalent, even though it's the same kind of label.What changed
badgeVariant?: 'default' | 'info' | 'success' | 'warning' | 'danger'onDevframeDockEntryBase, declared via the samedeclare module '@devframes/hub/types'merge this package already uses forDevframeDockEntryRegistry— no new field on the hub package itself.DockEntry.vue/DockEntries.vuethread it through, reusingTabs.ts's owncolorstoken map rather than inventing a second one.DockEntry.vuefalls back to its pre-existingbg-gray-6/text-whiteclasses at'default'/unset, and only switches to an inline-styled fill for an explicit non-default variant — every existing badge consumer keeps its current look, unchanged.Linked Issues
Additional context
Verified with
pnpm build,pnpm test(updated the public-API.d.tssnapshot for the new export, 381 passing total),pnpm typecheck,pnpm lint— all green.