liveBook · Manning

Edit state

As explained in Building User-Friendly DSLs

A book-specific object stored outside the abstract syntax tree that tracks editing state, including the original value and update operation for a projected DSL value.

Edit state is an object created during projection to manage interaction with one editable DSL value without changing the AST merely because editing has begun. It records the value being shown, whether it is in edit mode, and, when committing is supported, an operation that writes a replacement value back to the original AST setting. section 5.1.2 section 5.1.6

A value component receives an edit-state object rather than a bare setting. When inEdit is false, it renders a clickable value; clicking switches inEdit to true and renders a focused input. The input initially receives the projected value, while the AST remains the authoritative stored model. section 5.1.2 section 5.1.6

A practical edit-state object has three responsibilities:

  • Expose value, the current value supplied to the editor control. section 5.1.2
  • Track inEdit, which selects display mode or input mode in the value component. section 5.1.2
  • Provide setValue(newValue), a function that updates the associated AST setting when editing is committed. section 5.1.6

Commit behavior belongs in the value component’s event handling. Blur or Enter can call setValue and leave edit mode; Escape leaves edit mode without calling setValue, preserving the AST value. A number-oriented component additionally tests the input before committing it. section 5.1.6 section 5.2

Editing a rental setting

For a projected name setting, create observable edit state with value: settings["name"], inEdit: false, and setValue that assigns settings["name"]. Pass it to TextValue. The same shape can drive NumberValue for a rental price or discount setting, with numeric validation before setValue runs. section 5.1.6 section 5.2

Edit state is application state alongside the AST, but it serves a different purpose: the AST holds DSL data, whereas edit state holds transient editing status. Observable AST data and observable edit state let MobX-driven React components re-render as edits and commits change state. section 5.1.3 section 5.1.6

Figure 5.5 A reactive architecture for projectional editors, with application data split up into AST and edit state
figure

This architecture view separates persistent AST data from transient edit state in the reactive projectional editor. section 5.1.3

How Building User-Friendly DSLs covers it

How deep it goes
Defines object fields and event-driven commits, then refactors reusable text and number value-component machinery.
Examples
Uses rental names, prices, and discounts with TextValue and NumberValue components, including invalid-number input tests.
What it assumes
Explains edit state through plain JavaScript objects and React conditionals while deferring MobX setup to appendix B.4.
What you can do after
Build it from scratch by creating observable edit-state objects and committing validated input through setValue callbacks.
How it connects
Connects ASTs, projectional editors, React components, MobX, observability, and Transparent Functional Reactive Programming.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Building User-Friendly DSLs. The section links point to the parts of the book it draws on.