feat: field-kit — composable field widgets for json fields

[ilicfilip]

Problem

EmDash's json field type renders as a plain single-line text input in the admin. Editors have to type raw JSON by hand, which makes json fields effectively unusable for non-technical content editors.

The only way to get a usable editing UI for structured JSON data today is to write a native plugin with a custom React component. That's a high bar — most site builders shouldn't need to write React to get a form with a few sub-fields.

Proposal

field-kit is a plugin that provides composable field widgets for json fields, configured entirely through seed options — no React code required from site builders.

It ships 4 widgets:

Widget	Purpose	Stored value
object-form	Inline form for flat JSON objects	{ key: value, ... }
list	Ordered array editor with add/remove/reorder	[{ ... }, ...]
grid	Rows × columns matrix (toggle, text, number, select cells)	{ rowKey: { colKey: value } }
tags	Free-form tag/chip input	["tag1", "tag2"]

Example seed config

{
  "slug": "ingredients",
  "type": "json",
  "widget": "field-kit:list",
  "options": {
    "itemLabel": "Ingredient",
    "sortable": true,
    "fields": [
      { "key": "name", "label": "Name", "type": "text" },
      { "key": "amount", "label": "Amount", "type": "text" },
      { "key": "optional", "label": "Optional", "type": "boolean" }
    ],
    "summary": "{{name}} — {{amount}}"
  }
}

Design principles

• Configuration over code — everything driven by seed options, no React knowledge needed to use a widget
• Data-shape transparent — widgets store clean JSON; removing the plugin leaves valid data in the database
• Composable — 8 sub-field types (text, number, boolean, select, textarea, date, color, url) shared across widgets
• EmDash-native — uses FieldWidgetProps contract, Tailwind classes matching the admin design system

Implementation

Working implementation: https://github.com/ilicfilip/field-kit

The plugin uses the existing definePlugin() API with admin.fieldWidgets for widget registration and exports a fields component map from its adminEntry. Sub-fields are flat primitives — no nesting, keeping complexity bounded.

field-kit widgets on a product page — specifications (object-form), tags, features (list), and availability (grid):

Screenshot — field-kit widgets on a product page

Contributing this to emdash

I'm working with @jdevalk — we discussed this plugin and agreed it would be a great addition to core. I'd like to contribute field-kit to the emdash project, either as a first-party plugin in packages/plugins/ or integrated directly into core. Happy to adapt the code to whatever form makes sense once there's alignment on the approach.

Note

This plugin was developed with AI assistance (Claude).

[all3f0r1]

FYI #489 implements some of your proposal (though in a much simpler state), broadly available with 0.5.0.

However, I like your deeper approach much more than mine. Feel free to torture my code however you'd like.

[rob-j-oliver]

As this PR is aimed at people like me - non-technical content editors, I would love to see this ship. Great work!

[ilicfilip]

hey @all3f0r1 !

Thanks! I saw #489 - nice fix for the default case. field-kit builds on top of that: instead of editing raw JSON, site builders configure widgets (forms, lists, grids, tags) through seed options so editors never have to touch JSON at all.

Happy to build on your work and keep the textarea as the fallback when no widget is configured.

[all3f0r1]

Cheers ! Btw, are you planning on using Kumo (Cloudflare's UI library)? I know @ascorbic is pushing in that direction for any user-facing elements.

[ascorbic]

Yes, we should use Kumo for all admin elements, to keep things consistent.

[ascorbic]

Oh, this is super interesting! What do people think? Do we reckon this is a good approach here?

[dindinet]

I vote this for being in core

[jdevalk]

I really like and I think using Kumo should be no issue.

[all3f0r1]

I like the approach too.

[dindinet]

@ilicfilip Super solution. I vote this for core.

[ilicfilip]

Hi all - quick update:

I've ported the four widgets (object-form, list, grid, tags) from Tailwind to Kumo, matching the styling conventions used elsewhere in the admin. Strings are Lingui-wrapped and the widgets slot into ContentEditor.tsx's existing case "json": dispatch using bare widget names (e.g. "widget": "list"), while the pluginId:widgetName plugin-widget path stays
untouched.

Happy to open a PR against core if you'd like to merge it in - it's ready to go on a clean single-commit branch off main.

In the meantime I've also been exploring conditional field visibility (visibleWhen) on my fork - ilicfilip/field-kit#2 — which lets sub-fields show/hide based on other field values. Might be a nice addition to the fields story down the road once the core widgets land.

[ascorbic]

Thanks @ilicfilip. This is solid and I'm happy to take this forward as a first-party plugin, and probably enable it by default in templates. It looks like there's a mistake in the types in FieldDescriptor.options, so you can fix these in the same PR. Are there any other core changes that would be needed? I've not reviewed your code in detail, but we can do that in the PR.

visibleWhen looks good, but leave it to a follow-up.

[ilicfilip]

Thanks @ascorbic! Opened #702 with the plugin + the FieldDescriptor.options type fix you flagged. Rebased on latest main and green on typecheck / tests (30 new unit tests).

No other core changes needed as far as I can tell - the plugin drops into packages/plugins/ and the only packages/admin touch is widening the same type at the plugin-widget cast site. Happy to iterate in review.

visibleWhen left for a follow-up as you requested.

[ascorbic]

I'm closing this as the core is now implemented. Thanks @ilicfilip!