fix(workflow-form): let a card change its operator's siblings the way the panel does, so the HuggingFace task change persists on the form - #8839

What changes were proposed in this PR?

Closes #8762. Part of the Form View feature (#8011); from the #8439 refinements (item 3).

An exposed HuggingFace model picker (modelId) on the Form View offered a live task selector that could not persist. The card wrote back only the property it was bound to, under the binding's id, and the operator's other properties were a read-only copy with no controls behind them. Changing the task on the form switched the model list, but the operator kept its task; a reload showed the old one, and a model picked meanwhile was saved for a task the operator does not run.

The Form View is another way to show the canvas, so the fix makes the card behave like the operator property panel for the property it exposes, rather than freezing the selector:

• The field keeps the property's own key (modelId, not the binding id), so a widget that reaches itself or a sibling by key finds the same keys as on the panel. The card's model is the operator's properties, as the panel's is.
• The operator's other properties ride along as plain controls on the card's form (formly builds only the exposed field), so a widget finds its siblings on the card's form exactly as on the panel's -- the HuggingFace picker writes task through its control, which is also what announces the change, and resets the task-scoped fields through theirs; a control-level write lands in the model.
• The card writes back what it changed since it was built, in one edit (FormBindingService.writeProperties): the bound property and whatever siblings the widget changed with it, the way the panel writes its whole model. The comparison is against the card's own baseline, a clone of what it was built from, and the baseline is advanced by each write -- not against the operator as it is now, which would have sent back a sibling this card never touched but the canvas, a co-editor or another card on the same operator had changed in the meantime, putting the older value on top of the newer one (Copilot). The guard against formly's blank build-time default stays, for the bound property only.
• On the form a task change now does on the operator what it does on the canvas (new task, model and task-scoped fields reset), and the reader then picks a model for that task. An empty string and an absent property count as the same value in the write-back, so formly's blank for a property the operator never had is not written on every build (it put an empty property on the operator that the canvas's own form had left out).
• A held rebuild is also flushed by a click or a key, not only by the focus leaving: closing an nz-select leaves the focus in its search box, so no focusout fires, and a rebuild held while the list was open would have waited for an unrelated event (Copilot). The same deferred re-check decides it, so a filter still being typed is not thrown away. The click is listened for on the document rather than on this page: a dropdown's options are drawn in the CDK's overlay container, a sibling of the app, so the click that picks one -- or that picks the option already chosen, which changes no value and moves no focus -- never bubbles through the page (Copilot). The handler returns at once unless a rebuild is held. Keys stay on the page, where what is typed goes.
• Nothing that comes back for a task the widget has since left is shown: a model list or a failure (cached for the next asker instead), a poll waiting on another instance's request (stopped by the next load, whichever path that load takes), and a server-side search (the task change forgets the search -- the text, the results, the spinner it was waiting on -- and drops the search subscription with it, which discards both a query still sitting in the 300 ms debounce and a request already out; switchMap drops only a search the next search replaces, and a task change is not a search, so without that a typed query went out moments later under the task the widget had moved to, and its answer filtered that task's list under an empty search box (Copilot)): the fast paths return before the request still out is cancelled, so a slow first fetch could land after a cached task was already shown and paint its models under the other task's name (Copilot; also reachable on main by picking a second task while the first loads).
• Two more things the two views needed to agree on, found with both open on one workflow: the form held every rebuild while a closed dropdown kept the focus (nz-select leaves the focus on its search box after a pick, and the typing guard counted that as typing), so a change made on the canvas never reached the form until the reader clicked elsewhere -- a dropdown is typing only while its list is open; and the HuggingFace selector on the canvas kept showing the task it was built with when the form (or a co-editor) changed it -- it now follows its field's model on every change detection, as a local pick is followed, and reloads the models (the panel hides the schema's task field, so there is no control to listen to).

Any related issues, documentation, discussions?

Closes #8762. Raised by Copilot on #8437; filed from #8439. A first version froze the task on the form; dropped on the principle that the form stays consistent with the canvas, filling gaps rather than hiding controls. Known limitation, not this PR's: a card's context is read once per build, so between a co-editor's edit of the same operator on the canvas and the form's next rebuild the card can show a stale sibling (every seeded card today; tracked as a follow-up).

How was this PR tested?

Unit tests (vitest). The form's spec: the field is keyed by its property; the card's model carries the operator's other properties and its form carries them as controls; a sibling a widget changed is written back along with the bound value, in one call; only what the card changed is sent, so a sibling someone else changed in the meantime is left alone, and the baseline is advanced so a second edit sends only the second change; a sibling control's change lands in the model; an unchanged sibling emission writes nothing; a held rebuild is flushed by a click as well as by the focus leaving, and not while the list is still open (the host bindings exercised through real events in the rendered spec, including a click on an option inside a .cdk-overlay-container built outside the page, which the test first asserts the page does not contain); the existing write-back guards (unchanged value, blank before an edit, dirtied value, snapshot refresh) hold with the property key. The binding service's spec: writeProperties writes several properties over the current ones and is a no-op for a missing operator. The HuggingFace spec: on a card shaped as the form shapes it (bound field modelId, siblings as plain controls), a task change writes the task to the card's form, resets the model and the task-scoped controls, and the form hears it, which is what the card's write-back listens to; a task change arriving on the model shows the new task and loads its models, while the task already shown or a blank does nothing; a response or a failure that comes back for a task the widget has left does not replace the list it now shows; a task change cancels a search that is still out rather than leaving its spinner on or judging its answer later, drops a query still in the debounce (which then never goes out) and still allows a fresh search under the task now shown; and a poll started for an earlier task is stopped by the next load. The form's spec also pins that a selection made while a rebuild is held is written rather than lost to the rebuild, and that a card's value is compared under the property it is bound to rather than under the binding's id (Copilot). The form's spec also pins the typing guard (a closed dropdown's focused search box is not typing, an open one's is) and that formly's blank for a property the operator never had writes nothing. Each guard was deletion-checked and turned a named test red. eslint, prettier and the production (AOT) build pass; the full frontend suite passes; every line this PR adds is covered.

Checked by hand on a flag-on instance (main-demo, wid 14): on the form, switching the task to Text Generation reloads the model list; after the save the canvas panel shows the new task with the model cleared; picking a model on the form lands on the canvas; before the fix the same switch reverted on reload and the model was saved under the old task.

Video

Before

After

Was this PR authored or co-authored using generative AI tooling?

Yes. Generated-by: Claude Code (Claude Fable 5.1, Anthropic). Co-authored with Claude, reviewed line by line by the author before submission.

🤖 Generated with Claude Code