## Problem/Motivation `useDebouncedField` re-syncs its local state from the **string value** of `initialValue`: ```ts // ui/src/hooks/useDebouncedField.ts:55-58 // Sync local value when initial value changes (e.g., when selecting different node) useEffect(() => { setValue(initialValue); }, [initialValue]); ``` Because the dependency is the *value*, **any transient store write that changes a field's source value and then restores it destroys whatever the user has typed since**. The round trip registers as two dependency changes, and the second `setValue()` overwrites the user's in-flight local state. The field does not need to end up wrong for damage to occur — a there-and-back-again is enough. Split out from [#3589111](https://git.drupalcode.org/project/modeler/-/work_items/3589111), where exactly this destroyed keystrokes in the node label field. That instance was measured, not theorized: ``` t+0 edit commits; user keeps typing " Extra" -> "On Entity Update Extra" t+10ms stale write, then heal -> setValue() wipes it -> "On Entity Update" t+300ms the " Extra" keystroke's own debounce fires -> "On Entity Update Extra" ``` Note it was the **heal**, not the bad write, that did the damage. ### Scope: three fields, not one All three production call sites are in `ui/src/components/PropertyPanel.tsx` and share the hazard: | Field | Line | Source value | |---|---|---| | node label | `:483` | `node?.data?.label` | | node annotation | `:496` | `node?.data?.annotation` | | edge annotation | `:509` | `edge?.data?.annotation` | #3589111 removed the one known trigger, so **there is no known live reproduction today**. This issue is hardening: the hook remains willing to discard user input if any future code path writes and restores one of those values. Given that the last such path survived unnoticed for a long time and was only found while chasing an unrelated bug, the class is worth closing rather than the instance. ### The value-keyed sync is largely redundant already `PropertyPanel` **already** resets these fields on identity, flushing pending edits first so nothing is silently dropped: ```ts // ui/src/components/PropertyPanel.tsx:515-526 useEffect(() => { nodeLabelField.flush(); nodeAnnotationField.flush(); if (node) { nodeLabelField.setValue(node.data?.label || ''); nodeAnnotationField.setValue(node.data?.annotation || ''); } }, [node?.id]); ``` with the same pattern keyed on `[edge?.id]` at `:528-535`. So the hook's own comment — "e.g., when selecting different node" — describes a job the consumer is already doing correctly, and doing it *better*, because it flushes first. ## Proposed resolution **Do not simply delete the effect.** It still carries a case the identity effects do not: a change to the selected node's value that originates **elsewhere while selection is unchanged** — undo/redo being the obvious one, and model reload another. With the effect gone, an undo that restores a previous label would leave the input showing the newer text. That needs confirming before any change is made; it is the constraint that rules out the naive fix. The safer shape is to **suppress the sync while the user has uncommitted local edits** — i.e. skip `setValue` when a debounce timer is pending, since in that window local state is by definition more authoritative than the incoming prop. That preserves the undo/redo refresh while making it impossible for a transient write to clobber typing. Worth considering as alternatives: 1. Sync on a caller-supplied identity key rather than the value, so consumers say *when* a reset is legitimate. 2. Drop the effect entirely and rely on the consumer's identity effects — only if the undo/redo path proves to be covered elsewhere. ## Remaining tasks - [ ] Confirm whether undo/redo (and model reload) update these fields **through** this effect while selection is unchanged — this decides which option is viable - [ ] Implement the chosen option - [ ] Update `ui/src/hooks/__tests__/useDebouncedField.test.ts:43` `'should sync local value when initialValue prop changes'`, which pins the current behavior and will need to encode the new contract - [ ] Add a test proving in-flight typing survives a there-and-back-again write to the source value - [ ] Check the same reasoning against any other debounced inputs (`ContentEditableField`, token fields) that manage local state from a prop ## User interface changes None intended. The visible effect is negative: typing can no longer be discarded by an unrelated store write. --- Note: this issue was drafted by an AI agent, which verified every line reference above against `1.0.x` at `af20e47`.