yangzhang75 opened a new pull request, #8839: URL: https://github.com/apache/texera/pull/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 everything that differs from the operator, in one edit (`FormBindingService.writeProperties`): the bound property and whatever siblings the widget changed, the way the panel writes its whole model. The guard against formly's blank build-time default stays, for the bound property only. - The HuggingFace widget itself is unchanged: 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. ### 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; a sibling control's change lands in the model; an unchanged sibling emission writes nothing; 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. 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. ### 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](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
