Form editor: real-time input mapping panel with palette highlighting

[morissette]

What this does

While building a form for a screener, I ran into a frustrating UX gap: there was no way to see what data fields the benefits required, or which form component types were compatible, without leaving the Form Editor tab. This PR adds real-time visibility directly in the form editor toolbar.

Changes

Compact input status strip (top of Form Editor)

A horizontal pill bar replaces the previous hidden/drawer validation approach. It shows every required input path at a glance — no button click needed.

• Red pill (✗) — input path not yet mapped to any form field key
• Green pill (✓) — input path is covered by a field in the form

Palette highlighting on hover/click

Hovering a pill dims incompatible component types in the left-hand palette and outlines compatible ones with a sky-blue ring — so you know exactly what to drag onto the canvas.

Clicking a pill pins the highlight so it stays visible while you work. Click again to unpin.

Tooltip

A tooltip on each pill lists the compatible component types in human-readable form ("Text field", "Dropdown", etc.).

ARIA / keyboard support

• role="button", tabIndex, aria-pressed (pin state), aria-label (path + status + compatible types)
• Enter/Space activate the pin toggle
• Focus triggers the same palette highlight as hover
• role="tooltip" on tooltip divs; tooltip visible on group-focus-within as well as hover
• Decorative icon spans (✗ ✓ ⓘ) marked aria-hidden

Bug fix

extractInputPaths now correctly handles nullable JSON Schema union types (["null", "string"]) by skipping "null" before resolving the leaf type — previously it would take index 0, silently produce no compatible components for optional fields, and break the key dropdown filter.

Cleanup

• Removed two stray console.log statements in customKeyDropdownProvider and pathOptionsService

Screenshot

Form editor showing the input strip with one missing input (red), two mapped inputs (green), and the boolean-compatible palette components highlighted after hovering simpleChecks.tenYearTaxAbatement:

Testing

1. Create or open a screener with at least one benefit that has eligibility checks
2. Open Form Editor tab
3. Verify the FORM INPUTS strip appears above the canvas with red/green pills
4. Hover a pill → incompatible palette fields dim, compatible ones get a sky-blue outline
5. Click a pill → highlight pins (pill shows a ring); click again to unpin
6. Tab to a pill and press Enter/Space → same pin/unpin behaviour as click
7. Tab to a pill → tooltip appears and palette highlight activates without mouse

[morissette]

[Justin-MacIntosh]

I really like the UX ideas here!! I personally was struggling to find a good place to put the form paths (and the save button), and the idea to highlight the relevant Form Components is really good. This needs a pass in terms of the functionality though, there are a few missing pieces before this is ready to go in.

[Justin-MacIntosh]

issue: Unfortunately, this new function doesn't help when determining which FormPaths need to be filled out for a Selected EligibilityCheck. checkConfig().inputDefinition is the inputs "pre-transformation".

Right now the transformation logic for transforming the InputSchema of a Check to FormPath objects exists in the backend under FormDataTransformer and InputSchemaService. It's only accessible in the Frontend via the endpoint /screener/{screenerId}/form-paths, which returns FormPaths for a whole Screener, not individual checks. To do what you're doing here (which is a good idea for the UX!) we'll likely need another endpoint for returning the FormPaths of a CheckConfig object.

[morissette]

Thanks for the thorough review! Here's what was addressed:

Issues

• setFormSchema same-reference reactivity bug — changed to setFormSchema({ ...e.schema }) so every form edit produces a new object reference, fixing the InputsPanel not updating when dropdown selections change
• extractInputPaths using pre-transformation schema in SelectedEligibilityCheck — added transformInputDefinitionSchema() to the frontend utils (mirrors the backend InputSchemaService people/enrollments logic) and applied it before path extraction, so displayed paths match what the backend returns
• Tooltips not displaying — moved tooltip rendering to a Solid.js <Portal> with position: fixed coordinates from getBoundingClientRect, escaping the overflow-x: auto clipping context; works for hover and keyboard focus

Nits

• Palette highlight readability — extracted updatePaletteHighlight() as a named module-level function
• Duplicate pill markup — extracted a shared <InputPill status="missing"|"mapped"> component
• Pill ring clipping — added py-1.5 px-0.5 to the scroll container

Additional fixes found during review

• Click not driving palette highlight — the previous createEffect on hoveredPath ?? pinnedPath could silently no-op when TYPE_COMPATIBILITY[type] returned the same array reference. Replaced with an explicit highlight() helper called directly from each event handler (hover, hover-end, click). Added equals: false to the highlightedTypes signal so every update always propagates
• Pinned pill state not rendering — isPinned was destructured from SolidJS props, which evaluates the reactive getter once at creation time and captures a static false. Switched InputPill to the props-object pattern (props.isPinned) so it reads the live value on every render
• Pinned pill visual — pinned pills now show a darker background (bg-*-100 vs bg-*-50) to distinguish the active state (border-color approach was blocked by Bootstrap's .border { border: 1px solid #dee2e6 !important } from form-js)

[sierscse]

@morissette Interesting ideas! I'm the representative Benefits Analyst who configures screeners as a non-coder/SE. For me, I prefer the hidden validation panel. As we add more checks and the ability to configure longer, more complicated screeners, my concern is that it will look cluttered at the top of the page with a long list of checks. I'm adding questions first, then using the key drop down to connect the check. It's a bit of a chicken-and-egg issue. I like highlighting the possible inputs you can add based on the check, but configuring the screener is about adding questions first then connecting the checks. It's tough for me to imagine it would be intuitive for a non-software engineer Benefits Analyst to do that in reverse. BTW we also have a Slack UX channel to discuss UX ideas.

[morissette]

The biggest issue for me was when I added the inputs I didn't remember all the inputs and the less prominent validate button in the bottom right wasn't intuitively known to check. In addition I had to add like every input type to find the matching key to input type. Thanks for the slack mention; joined!