yangzhang75 opened a new pull request, #8845: URL: https://github.com/apache/texera/pull/8845
ISSUE: to be filed by Yang (text below the PR body) ### What changes were proposed in this PR? Closes #8844. Part of the Form View feature (#8011); from the #8439 refinements. Found on the #8761 demo (#8843). A compilation result rebuilt every card on the Form View, including the compilation a card's own write triggers. Three things followed from that, all visible with a Projection's drag-reorder list (#8761) and with any tick box: the controls were redrawn under the reader's eyes after every click (the row buttons flicker); the keyboard focus went with the replaced node, so a keyboard reader landed on the body about a second after every Move up / Move down; and a click made in the last 150 ms before the rebuild was lost, since the rebuild ended that card's pending debounced write and re-seeded the card from the operator, which still held the previous state (the row "jumps back"). The canvas's property panel redraws only when an operator's schema changes. The form now does the same: - A compilation rebuilds the cards only when it changed something they show: a card's operator schema (the column enums compilation writes into it, which turn an attribute box into a dropdown), the set of inputs (an operator deleted on the canvas makes its card broken; a property exposed or removed), or an operator value a card does not hold (a co-editor's edit). A card's own edit, written back or still on its way, is not a reason: the two agree once it is written. The result picker and the shown results still follow the graph on every compilation. - Before any rebuild, from any source, a card's unwritten edit is written, so a rebuild can no longer lose one. - An empty string and an absent value count as the same value in the comparison (formly's blank default for a property the operator never had), so such a card is not rebuilt on every compilation. ### Any related issues, documentation, discussions? Closes #8844. The drag-reorder list #8843 (#8761) brings to the form is where this is plain to see: every Move writes and compiles, and the row's buttons redraw, lose the focus and can undo a quick second Move. The cause is the form's own compile handling, present since the cards were first built from the compiled schema; on main alone a tick box goes through the same redraw, focus drop and lost second click, which take a keyboard or a stopwatch to notice. The Before/After below is therefore recorded on top of #8843 (before: #8843 alone; after: #8843 plus this); this PR does not depend on #8843 and applies to main as is. Known limitation, unchanged: a card still shows a co-editor's edit of the same property only after the rebuild that edit's compilation triggers (tracked as a follow-up). ### How was this PR tested? Unit tests (vitest), the form's spec: a compilation that changes nothing a card shows leaves the cards alone (same card objects) while the result picker is still refreshed; a changed operator schema, an operator gone from the graph, an operator value changed under a card (a co-editor's edit), a changed set of inputs (one exposed; a shown one turned broken) each rebuild; an author's broken card is left alone; the card's own edit does not rebuild while pending nor once written; formly's blank and an absent value count as the same; an unwritten edit is written, once, before a rebuild from any source replaces the card; a read-only viewer's card has no write to flush; the typing hold still holds a needed rebuild until the focus leaves. Each guard was deletion-checked (every compilation rebuilding; the schema check, the pending check, the broken-set check, the blank normalisation, the pre-rebuild flush, the pending mark, the pending reset and the result-picker refresh each removed; a br oken card checked against a schema) and turned a named test red. eslint, prettier and the production (AOT) build pass; the full frontend suite passes; every statement, function and branch this PR adds is covered. Checked on a flag-on instance (main-demo; before = main, and main + #8761; after = the same plus this), a Projection's columns and its Drop Option exposed on the form. The tick box on main: 0.3 s after a tick the box still has the focus; 2.8 s later it is a new DOM node and the focus is on the body; two ticks 700 ms apart end in the state after the first (the second undone). The drag-reorder rows on main + #8761: after a Move down the row's buttons are replaced about a second later, the focus is on the body, and a second Move down 700 or 750 ms after the first is undone (the row jumps back). With this change: after a Move down the row's buttons are the same DOM nodes three seconds later, the focus is still on the moved row's Move down button, and seven timed pairs of Move downs from 500 to 900 ms apart all land. With a canvas tab open beside the form, a change made on the canvas still reaches the form within a second (a value the card does not hold rebuilds it), and the form's cha nges reach the canvas panel. #### Video **Before** _(to be added)_ **After** _(to be added)_ ### 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]
