Repository navigation
Spike: Node-edit interaction & UX (design) #238
Description
Description
Design how node editing looks and behaves.
Two central questions:
- Save model - does the user click a field, edit, and click away (blur) to commit, or is there an explicit Save button? Plus dirty / unsaved state, discard, and per-field vs whole-node editing
- Validation model - when do we validate (live as-you-type, on blur, or only on save) and who validates: SDK-only (reuse the existing validateWorkflow / produced errors after the edit is written back and re-parsed - simple, one source of truth, but feedback lags a full round-trip) vs some validation in the editor
Investigate, comment on ticket and discuss with team
Motivation
The save + validation models shape the whole feel of editing and have real trade-offs. Blur-to-save is fast but risks accidental commits; an explicit Save is clearer but heavier. SDK-only validation keeps one source of truth but only reacts after a round-trip (so a structural edit is rejected late); in-editor pre-checks catch bad edits earlier but add a second validation surface to keep in sync. These need deciding before implementation so the feature is built once.
Proposed Implementation
No response
Definition of Done
- Implementation: Fully implemented according to the Serverless Workflow spec.
- Unit Tests: Comprehensive unit tests are included and passing.
- Integration Tests: Verified within the monorepo and target environments (Web/VS Code).
- Documentation: Updated README.md, ADRs, or official docs.
- Performance: No significant regression in editor responsiveness.
- Accessibility: UI changes comply with accessibility standards.
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
lornakelly commentedon Jul 29, 2026
Reviewed and discussed with team
Decided on an explicit Save/Cancel model per node because undo / redo will be critical - and an undo stack is only coherent when each user action maps to one discrete commit. Commit-on-blur produces a commit per field; a Save button produces one commit per deliberate save. So it's what makes clean undo/redo possible.
Main features:
isReadOnly. When true, rows render as plain display values - no controlsOpen question: whether we do validation on Save and display errors as we do today or if we do per field validation (currently under review - #284)