# Form library bridge > Drive grid edits from a form library - Felte, Superforms, Formsnap, > or a plain `

`. `api.setCellValue` is the single write surface; > any UI that funnels through it stays consistent with inline editing. ## When You want the same row to be editable two ways: - **Inline** via the grid's built-in editors (commit on blur) - **Drawer / modal** via a form library with its own validation Both writers must update the SAME underlying data so users can edit either way and not lose work. Common in admin tools, CRMs, and audit queues where some fields are best inline (status pill) and others need a real form (long-text + validation + dependent dropdowns). ## The pattern The examples on this page run against these rows: ```svelte ``` ``` ┌──────────────────┐ setCellValue(idx, field, v) ┌──────────┐ │ Inline editor │ ──────────────────────────────────────────► │ data[] │ └──────────────────┘ │ $state │ │ │ ┌──────────────────┐ setCellValue(idx, field, v) │ │ │ Drawer │ ──────────────────────────────────────────► │ │ └──────────────────┘ └──────────┘ ``` Same write path. Same dirty tracking (count `onCellValueChange` events). Whatever lives in `data[]` is the truth. ## Wire-up ```svelte r.id} onApiReady={(a) => (api = a)} onCellValueChange={onCellChanged} /> {#if draft} { e.preventDefault(); submit() }}> Name {#if errors.name}{errors.name}{/if} Email {#if errors.email}{errors.email}{/if} Salary Save → setCellValue {/if} ``` ## Plugging Felte / Superforms Same pattern with the library's idiomatic surface: - **Felte**: bind the form to `draft`; the library handles validation. In `onSubmit`, call `api.setCellValue` for each changed key. - **Superforms**: pass `selected` as the initial form data; on submit, the validated `form.data` becomes the source of `setCellValue` calls. - **Formsnap**: a Superforms shape with built-in field components. Same `onSubmit` plumbing. The library doesn't care which form library renders the inputs - the contract is just "after validation, call `api.setCellValue` per dirty field". ## Tracking "dirty" across both UIs Two valid strategies: 1. **Event count** (shown above) - simplest. Reset to 0 after a save. 2. **Snapshot diff** - keep an initial copy of the data array; `JSON.stringify(initial) !== JSON.stringify(api.getData())` is dirty. More accurate, more expensive. Most apps want #1. ## Try it `api.setCellValue` is the single write surface. A plain form funnelling through it stays consistent with inline editing - edit either way and both agree. ```svelte

City for row 1 Apply

(api = next)} /> ``` ## See also - [Side-drawer edit demo (97)](https://svgrid.com/demos/97-side-drawer-edit/) - the slide-in pattern used as the form host - [Submit-time validation recipe](https://svgrid.com/docs/recipes/submit-time-validation/) - similar bulk-commit-then-validate pattern - [Undo / redo for grid edits](https://svgrid.com/docs/recipes/undo-redo-edits/) - layer history on top of the same `setCellValue` calls - [`SvGridApi.setCellValue`](https://github.com/sv-grid/sv-grid/blob/main/docs/reference/SvGridApi.md#setcellvalue) --- SvGrid is the Svelte 5 data grid (`npm install @svgrid/grid`, MIT). This page: https://svgrid.com/docs/recipes/form-library-bridge/ . All docs: https://svgrid.com/llms.txt