Separate immediate and authoritative checks
Use cell validation for type, required-value, range, and formatting feedback. Use row validation for cross-field rules. Send uniqueness, permissions, current-state, and business-policy checks to the server before treating an edit as saved.
Choose blocking behavior deliberately
Block commit when accepting the value would make the task unsafe or ambiguous. Allow commit with a warning when the user may continue and resolve the issue later. Keep informational feedback distinct from errors so every marker does not feel equally severe.
Handle bulk changes precisely
Paste, fill, import, and multi-row actions need outcomes keyed by stable row and column identity. Preserve successful changes, identify rejected fields, and return the authoritative value or version after conflicts. Avoid replacing a whole batch with a generic failure message.
Make errors accessible
Do not rely on color or a corner marker alone. Associate the message with the cell, expose invalid state to assistive technology, preserve keyboard focus, and provide a way to review errors without scanning every visible row.
Product evidence
Validation behavior is configurable
Ace Grid documents validation mode, trigger, indicators, visibility controls, and application callbacks so teams can match feedback to their persistence workflow.
Live Ace Grid example
Editable account review grid
Show warnings and blocking errors next to the affected business values.
Enable validation for editable cells
import { Grid } from "@ace-grid/pro";
<Grid data={{ rows, columns }} edit={{ enabled: true }} validation={{ enabled: true, mode: "block", trigger: "commit", indicator: "corner" }} />;Limitations and tradeoffs
- Client-side validation cannot replace authorization or authoritative business checks.
- A read-only reporting table does not need editing validation infrastructure.
Common questions
Can validation run on the server?
Yes. Use immediate client feedback for responsiveness, then map server outcomes back to stable row and column identities before confirming persistence.
Should invalid edits always be blocked?
No. Block unsafe values, but use warnings when the workflow permits temporary or reviewable exceptions.