Searchable select & plugin field widgets in repeater sub-fields

[swissky]

Summary

Two related improvements for select editing inside repeater sub-fields:

1. (focused, PR ready) Make repeater sub-field select a searchable combobox.
2. (broader) Let plugin field widgets apply to repeater sub-fields, not just top-level fields.

Motivation

Repeater rows frequently bind a select sub-field to a large, often taxonomy-derived option set. Today SubFieldInput (in RepeaterField.tsx) renders a plain Select for type: "select", so a list of dozens/hundreds of options is a long scrolling dropdown with no filtering — painful to use per row.

Concrete real-world case: a clinic directory where each clinic has services and diagnostics repeater fields, and each row's name is a select whose options come from a treatments/diagnostics taxonomy. Editors pick from a large list per row.

Proposal 1 — searchable sub-field select (focused)

Render select sub-fields with the Kumo Combobox (typeahead) instead of Select, matching the search-as-you-type pattern. Small, self-contained change in RepeaterField.tsx. I've opened a focused PR for this.

Proposal 2 — field widgets in repeater sub-fields (broader)

The plugin fieldWidget API (field.widget = "pluginId:widgetName") is currently resolved only for top-level fields in ContentEditor.tsx (FieldRenderer). Repeater sub-fields go through RepeaterField → SubFieldInput, which switches purely on subField.type; RepeaterSubFieldDef has no widget property and there's no widget resolution there.

Extending field-widget support into sub-fields would let plugins provide custom editing UIs inside repeaters (e.g. a taxonomy-backed combobox), without anyone having to patch the admin bundle. This is bigger (schema widget on sub-fields, the sub-field editor UI to set it, persistence, and plumbing pluginAdmins/manifest into SubFieldInput), so raising it here first per the contribution policy.

Happy to work on Proposal 2 as a follow-up if maintainers are interested in the direction.

[diegoaguilar]

Relevant use case for this: a variants[].attributes[] editor (per-variant {key,value} spec rows). Being able to attach a widget: "pluginId:name" to a repeater sub-field — the thing proposed here — is exactly what would let a per-variant attributes editor work without wrapping the whole variants field in a custom json widget. Strong +1 on extending widget resolution into repeater sub-fields.

[cyface]

+1 on both proposals, with a supporting use case for Proposal 2 and a related surface worth keeping in view.

Use case: our site has a "cards grid" section block where an editor picks N content entries to feature. What we want per row is an entry picker — a searchable combobox backed by a collection query. Because nothing richer than a plain scalar input can render per row today, the block instead exposes a multiline text field of entry slugs, split on newline at render time. It works, but it's the least editor-friendly field in our admin: typos are silent and there's zero discoverability. A widget: "pluginId:name" on repeater sub-fields is exactly the extension point that would fix this without core having to know what an "entry picker" is.

The related surface: the same sub-field limitation exists in the Portable Text custom-block field modal (plugin-registered block types). Our testimonials block has a repeater of { quote, author, avatar, … } where avatar must be a hand-typed URL string for the same reason — no widget (e.g. media picker) can render inside a repeater row there either. If widget resolution gets extended past top-level fields, it would be worth plumbing it through both RepeaterField in the content editor and the block-modal sub-fields, since plugins hit the identical wall in both places.

(Posted with AI assistance — Claude Code / Claude Fable 5, from @cyface's session; details are from our production plugin.)

[cyface]

Following up on my earlier comment with a second, narrower case for Proposal 2 — and a smaller alternative that would cover it if full widget resolution in repeater rows is too big a lift.

Use case: a per-row "override in effect" indicator. Our cards-grid section block has a placements repeater where each row names a content entry (slug) and optionally overrides three of that entry's fields for this page only (hookText, takeText, bestFor). Blank means "use the entry's own value"; non-blank means "this page's copy wins". Editorially that's fine until the entry's default changes weeks later and nobody remembers which pages carry a hand-typed override. We want the row itself to say "Override in effect — entry default: <excerpt>" (or "Using entry default"), so the stale copy is visible at edit time, right where it would be fixed.

Nothing in a repeater row can render that today. Against the installed @emdash-cms/blocks 0.36.0 typings:

• RepeaterSubField is TextInputElement | NumberInputElement | SelectElement | ToggleElement — no read-only/context/custom element inside a row.
• TextInputElement carries only placeholder/initial_value/multiline, so not even static per-field help text.
• SelectElement.optionsRoute does reach back into a plugin route, but the route receives no row context (no slug), so it can't compare the row against its entry.
• context/section/banner exist only at block level, outside the rows.

Two shapes that would fix it:

1. Proposal 2 as written — widget: "pluginId:name" on repeater sub-fields, reaching both RepeaterField in the content editor and the Portable Text block-modal sub-fields (our block lives in the modal). A plugin widget with access to its row's values covers this and the entry/media-picker cases above.
2. A narrower per-row context sub-field — a read-only text element allowed in RepeaterElement.fields, whose text is either static or fetched from a plugin route that (unlike optionsRoute today) receives the row's current values. Much smaller surface than widgets, and it's enough for "compare this row to its source record and say so".

Either would let us build this without patching the admin bundle. Tracking on our side as an open issue pinned to RepeaterSubField changing; happy to test a branch.

(Posted with AI assistance — Claude Code / Claude Fable 5.1, from @cyface's session; details are from our production plugin.)