Interface: EditRequest<TProps>
Defined in: model/edit-request.ts:18
What the extension hook reads (D4). It carries the same three members on a preview call
and on the real commit call, which is why an extender can never refuse a write — see the
refusal note: a lock plugin vetoes in beforeChange, never here.
Type Parameters
TProps
TProps = Record<string, unknown>
Properties
addedEntryIds
readonlyaddedEntryIds:ReadonlySet<EntryId>
Defined in: model/edit-request.ts:39
The Entries this transaction adds, by id — empty on a drag preview, and empty whenever the
transaction adds none. Read one with entryAfterEdits(id): an added Entry is not in entries
above, which stays the pre-transaction snapshot. Net effect, not a call log: an Entry
added and removed in the same transaction is in neither set (#235).
entries
entries:
ReadonlyMap<EntryId,StoredEntry<TProps>>
Defined in: model/edit-request.ts:22
Current store snapshot, before this transaction's edits — what a cascade reads to compute a
delta (what moved, and by how much). Unlike entryAfterEdits below, this never reflects this
transaction's own body edits.
proposed
proposed:
ProposedEdits
Defined in: model/edit-request.ts:26
What the caller asked to change — storage-shaped and complete, the same as entries above
(plans/02, "core fills zone math"): a cascade compares it against entries with no
normalizing step of its own.
removedEntryIds
readonlyremovedEntryIds:ReadonlySet<EntryId>
Defined in: model/edit-request.ts:43
The Entries this transaction removes, by id — descendants included, because entries.remove
removes the whole subtree and core fills the descendant walk. Read one off entries above,
which still holds it: entryAfterEdits(id) answers undefined for every id in here (#235).
Methods
editableOf()
editableOf(
id,field):FieldEditable
Defined in: model/edit-request.ts:56
The effective lock on this cell (#473): a plugin's per-entry lock rule's own answer, or the
Field's own editable when the rule has no opinion. An undeclared key or a compute Field
answers 'never', same as Dataset.editableOf. Reads write-rule.ts's editableAnswerFor,
the same resolver every write door reads (I14) — a cascade checks the same lock
entries.update() and the grid check before it writes.
Parameters
id
string | EntryId
field
Returns
entryAfterEdits()
entryAfterEdits(
id):StoredEntry<TProps> |undefined
Defined in: model/edit-request.ts:34
id as this transaction's own body edits leave it: committed state overlaid with proposed
(and, at commit, this transaction's own adds). undefined when id names no entry there either.
entries.get(id) is the wrong read for judging an in-flight edit against current shape — it
still shows an Entry's dates as they were before this transaction rewrote them, so a cascade
reasoning from it can propose a write core then refuses against the shape it actually has
A per-id lookup, not a second map on this object: the drag preview calls this every
rAF frame and must not copy the dataset to answer it (I5).
Parameters
id
string | EntryId
Returns
StoredEntry<TProps> | undefined
hasChildren()
hasChildren(
id):boolean
Defined in: model/edit-request.ts:46
Has this row a child, as this transaction's own body and adds leave it? Same tree
entryAfterEdits(id) reads.
Parameters
id
string | EntryId
Returns
boolean
writeTarget()
writeTarget(
id,field):WriteTarget
Defined in: model/edit-request.ts:50
Where does a write to this cell land — on the row, split across its children, or nowhere?
A cascade that writes a cell it does not own is dropped in silence (ADR 0013, decision 5).
Reads write-rule.ts, the resolver the grid and update() read (I14).
Parameters
id
string | EntryId