Skip to content

feat(hub): client-registered client-only docks via docks.register/update#129

Merged
antfu merged 2 commits into
mainfrom
feat/hub-client-docks-register
Jul 23, 2026
Merged

feat(hub): client-registered client-only docks via docks.register/update#129
antfu merged 2 commits into
mainfrom
feat/hub-client-docks-register

Conversation

@antfubot

Copy link
Copy Markdown
Collaborator

What

Adds client-side docks.register() and docks.update() to the hub's client host context (DevframeClientContext.docks), so a client host can contribute dock entries that live only in the page.

Why

Until now the client could only consume docks projected from the node hub via the devframe:docks shared state. There was no way for a host page to synthesize a dock of its own. This mirrors the existing client commands.register() pattern (a local map merged with the read-only server source), giving symmetry between the two client-side registries.

Behavior

  • docks.register(entry, force?) adds a client-only entry — never written to shared state, so it stays local to this client instead of syncing to the hub or other viewers. Returns a handle with update(patch) (id immutable) and dispose().
  • docks.update(entry) replaces a previously client-registered entry wholesale.
  • Client-only docks merge into the same docks.entries/groupedEntries, participate in selection/entryToStateMap, and load their client scripts exactly like server docks. A client dock sharing an id with a server dock overrides it locally.
  • Registering a duplicate client id throws unless force is passed; updating an unknown id throws.

Notes

  • New DockRegistration<T> type exported from @devframes/hub/client; tsnapi client API snapshot updated accordingly.
  • Covered by new client host tests; docs added under the Client Context guide.

This PR was created with the help of an agent.

Let a client host contribute dock entries that live only in the page,
merged with the server docks from shared state without syncing back to
the hub or other viewers — mirroring the client commands.register pattern.
@netlify

netlify Bot commented Jul 23, 2026

Copy link
Copy Markdown

Deploy Preview for devfra ready!

Name Link
🔨 Latest commit c7ef7ec
🔍 Latest deploy log https://app.netlify.com/projects/devfra/deploys/6a617de8ac99cc00083076d8
😎 Deploy Preview https://deploy-preview-129--devfra.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.
🤖 Make changes Run an agent on this branch

To edit notification comments on pull requests, go to your Netlify project configuration.

Register a client-only "Client Notes" dock on the client host context in
both minimal hub examples, source the dock list from the merged
context.docks.entries, and show update()/dispose() on the returned handle.
@antfu
antfu merged commit caf318b into main Jul 23, 2026
12 checks passed
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants