SYIDAX / DATA GRID

Batch editing PRO

Collect changes, then apply or cancel them together.

Get started
Batch editingSample order data
120 rows
Loading Grid…

Options

Changes below update the Grid and code immediately.

Latest result

Start a session using the Grid's batch editing tools. The Batch editing tools option below controls their visibility.

View code
Current preview

Usage guide

#

Suitable for changing multiple cells before saving them together or cancelling all changes. Distinguish pending values from committed ones.

Try it yourself

  1. Start batch editing

    Start a session using the Grid's batch editing tools. The Batch editing tools option below controls their visibility.

  2. Edit several cells

    Change quantities for two orders and review the pending changes before committing.

  3. Compare commit and cancellation

    Commit through the tools to apply changes. Start another session, edit values, then cancel to verify pending edits are discarded.

Expected results

Apply or cancel multiple changes within a session at once.

getPendingBatchCells() reads uncommitted cells. Implement server submission after the Grid commit in your app.

Useful terms

Batch editing
Collecting several edits into one operation.
pending
An edited value that has not yet been committed.

Using this feature in your product requires the Pro runtime and a valid license.

API reference

#

Other properties1
Attribute / PropertyType / DefaultDescription
PRO
batchEditToolbar
booleanDefault: falseStart / review / apply / cancel controls for client-side batch edits (Grid Pro).
Events2
EventsDetail typeDescription
PRO
SyGridBatchEditStartEventDetailone per sealed batch transaction: the ledger opening.
PRO
SyGridBatchEditEndEventDetailthe status-keyed batch transaction verdict (ledger close).
Methods6
Method / ArgumentsReturn typeDescription
PRO
options?: SyGridBatchStartOptions
Promise<boolean>open a batch edit session . True when started or joined.
PRO
Promise<boolean>whether a batch session is live.
PRO
rowId: GridRowId, colId: string, value: unknown
Promise<boolean>stage one identity-keyed cell into the live batch. Identity must resolve to a current row and a declared column; display coords ride along for the overlay seam only. Nothing is written to the model until `commitBatchEdit`.
PRO
Promise<SyGridPendingBatchCell[]>the pending (staged, uncommitted) batch cells in first-staging order. The public pull surface for the visibility layer: the renderer overlay itself is deferred to Phase F (wiring the per-consumer pending policy into the shared cell text resolver would put a batch branch into every sealed render/copy/aggregation path — measured too regression-prone for this batch; recorded honestly in the daily note).
PRO
Promise<number>cancel the live batch through the ledgered API cancel: one minted cancelled transaction (batchEditStart → batchEditEnd with `reason: 'api'`), zero writes, typed dropped count.
PRO
options?: SyGridBatchCommitOptions
Promise<SyGridBatchCommitReport>commit the live batch through the recovery-capable async core: one mint per flight, strongest-first fail-closed gates (RBAC → validation), partial-invalid policy ('reject-all' default — the session survives a refusal with pending intact; 'commit-valid' writes the valid subset and keeps invalid cells pending). Accepted writes apply through the single-authority `applyTransaction` route between the ledger's start and end events.