feat(hub): reinterpret grouped dock entry category as in-group sub-category#130
Merged
Conversation
…tegory Adopt the refined dock-grouping semantics downstream viewers are moving to: when a dock entry's groupId resolves to a registered group, the group's own category is the entry's outer dock-bar bucket, and the entry's own category is reinterpreted as an in-group sub-category. Orphan entries (groupId with no registered group) keep using their own category as the outer bucket. - Document the dual role of category/groupId and the group's category on the types (DevframeDockEntryBase, DevframeViewGroup) plus the hub grouping docs. - Make the client host's groupByCategory bucket grouped members under their group's category (default fallback), orphans under their own, so hub's own groupedEntries agrees with the refined semantics for standalone viewers. - Reconcile DEFAULT_CATEGORIES_ORDER to put framework first (matching what Vite DevTools ships) and export it from the main, node and client public entry points so downstream kits can import the single source of truth. Created with the help of an agent.
✅ Deploy Preview for devfra ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Extend the known dock category vocabulary with four more buckets and slot
them into DEFAULT_CATEGORIES_ORDER between the existing ones (intentional
weight gaps let kits interleave their own):
- ui (150) — components, design system, styling
- data (250) — state, storage, queries, database
- performance (350) — profiling, metrics, budgets
- docs (500) — documentation, references
Also list the full category vocabulary in the hub grouping docs. The
DevframeDockEntryCategory union still allows arbitrary strings via
`(string & {})`, so kits keep passing custom ids.
Created with the help of an agent.
antfubot
added a commit
that referenced
this pull request
Jul 23, 2026
Implement the hub side of the shared-iframe soft-nav design: extend DevframeViewIframe with navTarget + a subTabs anchor flag (and NavTarget / FrameSubTabsConfig types), and ship a viewer-side frame-nav adapter (attachFrameNavClient) that the client host auto-attaches to a subTabs anchor iframe. The adapter runs a versioned, origin-locked host<->iframe postMessage handshake, materializes one client-only member dock per reported tab (via the client docks.register from #129, keyed <frameId>:<tabId>), and drives a bidirectional nav loop: selecting a member posts navigate; the app's navigated report moves the dock highlight. An idempotent guard breaks the echo, a declarative manifest snapshot reconciles add/update/remove (clearing selection when the active tab vanishes), and a handshake timeout degrades to no-shim (anchor stays a single plain iframe dock). Grouping stays orthogonal to frameId and follows the #130 category rule. Covered by client host + adapter tests; hub API snapshots updated.
This was referenced Jul 23, 2026
Merged
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.
Intent
Dock entries carry a
category(their outer bucket on the dock bar) and an optionalgroupId(flat membership pointer that collapses an entry under a group's button). Downstream viewers (e.g. Vite DevTools) are adopting a refined rule where these two fields cooperate:No new field is introduced — the existing
categoryis reinterpreted based on whethergroupIdresolves.This PR makes the hub side consistent with that rule and documents it.
What changed
packages/hub/src/types/docks.ts) — document the dual role ofcategoryandgroupId, the group'scategoryas the shared outer bucket for the group button and all its members, and thedefault/orphan fallbacks. Keeps the "grouping is one level deep" invariant.packages/hub/src/client/host.ts) —groupByCategorynow buckets a member whosegroupIdresolves to a registered group under the group's category (falling back to'default'); orphan members (unregistered group) keep their own category. Hub still does not render the group-collapse popover — this only fixes which outer bucket a grouped member lands in for standalone hub viewers.packages/hub/src/constants.ts) —DEFAULT_CATEGORIES_ORDERnow putsframeworkfirst (framework: -100), matching what Vite DevTools ships. It's now exported from the main, node, and client public entry points (in addition to./constants) so downstream kits can import the single source of truth.default), and orphan members (own category), plus category ordering (framework first).docs/guide/hub.mdgrouping section now describes the dual role and fallback/orphan rules;docs/guide/client-context.mdgroupedEntriesnote clarified.Fallback rules honored
category→ members' outer bucket is'default'.groupIdbut nocategory→ its in-group sub-bucket is'default'.groupIdreferencing an unregistered group → entry renders top-level using its owncategory.Gates run:
pnpm lint,pnpm vitest run(850 passed),pnpm typecheck,pnpm build— all green.This PR was created with the help of an agent.