Clear and concise description of the problem
The json-render dock format is a great way to build a devtools panel — declarative, server-owned, no client build. But it currently comes bundled with one specific look: a consumer who wants the format has to accept the reference @antfu/design component set too.
It would be useful to keep the tooling and supply your own component library / registry / catalog instead.
devframe already supports exactly this. @devframes/json-render documents renderer replacement as a first-class extension point, and initHub takes the registrations (packages/json-render/src/hub.ts):
Implement it to replace the reference frontend — register the implementation locally (createDevframeClientHost({ renderers })) or ship it as a prebuilt module registered through the hub's renderer manifest (initHub({ renderers })).
@vitejs/devtools hardcodes that array, so the seam isn't reachable from a plugin or from vite.config.ts:
Suggested solution
Expose the renderer registrations devframe already accepts, so a consumer can override the json-render renderer (and keep the reference one as the default).
Currently type & schema enforcing is quite permissive, but we might want to have a more declarative schema/type so that downstream renderer now what is currently supported and what isn't ?
If you're open to the idea, I'm happy to work on it.
Alternative
custom-render docks are the closest public alternative, but they drop the json-render spec transport entirely, so you end up re-implementing it. Patching @vitejs/devtools works but lands in a hashed dist/ chunk, so it breaks on every release.
Additional context
What it would enable: rendering json-render docks with a design system, so a team's tooling matches the product it fronts and picks up design-system changes for free. The renderer contract is already framework-agnostic ("The renderer owns its framework (Vue, React, …)"), and the protocol itself needs no changes — a custom renderer reuses the same catalog prop schemas.
Clear and concise description of the problem
The
json-renderdock format is a great way to build a devtools panel — declarative, server-owned, no client build. But it currently comes bundled with one specific look: a consumer who wants the format has to accept the reference@antfu/designcomponent set too.It would be useful to keep the tooling and supply your own component library / registry / catalog instead.
devframe already supports exactly this.
@devframes/json-renderdocuments renderer replacement as a first-class extension point, andinitHubtakes the registrations (packages/json-render/src/hub.ts):@vitejs/devtoolshardcodes that array, so the seam isn't reachable from a plugin or fromvite.config.ts:packages/core/src/node/server.ts#L71packages/core/src/node/build-static.ts#L80Suggested solution
Expose the renderer registrations devframe already accepts, so a consumer can override the
json-renderrenderer (and keep the reference one as the default).Currently type & schema enforcing is quite permissive, but we might want to have a more declarative schema/type so that downstream renderer now what is currently supported and what isn't ?
If you're open to the idea, I'm happy to work on it.
Alternative
custom-renderdocks are the closest public alternative, but they drop thejson-renderspec transport entirely, so you end up re-implementing it. Patching@vitejs/devtoolsworks but lands in a hasheddist/chunk, so it breaks on every release.Additional context
What it would enable: rendering
json-renderdocks with a design system, so a team's tooling matches the product it fronts and picks up design-system changes for free. The renderer contract is already framework-agnostic ("The renderer owns its framework (Vue, React, …)"), and the protocol itself needs no changes — a custom renderer reuses the same catalog prop schemas.