BbDataGrid has no editing of any kind. Consumers who need it hand-build an editable surface out of CellTemplate and their own inputs, which is where #464 comes from — that reporter wants a JS-free BbNumericInput because they are placing 200 of them in a grid to get Excel-like editing. A real editing mode serves that need better than the thing they asked for, and probably closes that issue too.
This is the clearest remaining gap against the mainstream Blazor grids. Radzen, Syncfusion and MudBlazor all ship inline and cell editing with validation.
Proposed shape
<BbDataGrid EditMode="DataGridEditMode.Row" OnRowCommit="Save">
<BbDataGridPropertyColumn Property="x => x.Name" Title="Name">
<EditTemplate>
<BbInput @bind-Value="context.Name" />
</EditTemplate>
</BbDataGridPropertyColumn>
</BbDataGrid>
EditMode — None (default, nothing changes), Row, Cell.EditTemplate per column, falling back to a type-appropriate editor when not supplied.OnRowCommit / OnRowCancel, both cancellable, carrying the edited item.- Validation through the existing
EditContext, so DataAnnotations work without a second mechanism.
- Keyboard — Enter commits, Escape cancels, Tab moves cell to cell in
Cell mode.
What makes this hard
Not the editors. The interactions:
- Virtualization. An editor scrolled out of view is unmounted; its in-progress value must survive that, or a long grid silently discards edits on scroll.
- Sorting and filtering. A row edited so it no longer matches the current sort or filter should not jump or vanish under the cursor mid-edit. Commit is the natural point to re-evaluate, not keystroke.
- Row context menu and selection. Both currently own the click; editing needs a share of it, and
Cell mode needs a cell-level hit target that does not exist yet.
- Hierarchy rows. Editing a parent while children are lazily loaded needs a decision — probably disallow, but it should be a decision rather than an accident.
Scope
Suggest landing Row mode first and Cell mode second. Most of the complexity above is cell-specific, and row editing alone covers the common case. Shipping half of this well is better than shipping both badly.
Part of the DataGrid sweep — see the plan for ordering against #463, #456 and #412.
BbDataGridhas no editing of any kind. Consumers who need it hand-build an editable surface out ofCellTemplateand their own inputs, which is where #464 comes from — that reporter wants a JS-freeBbNumericInputbecause they are placing 200 of them in a grid to get Excel-like editing. A real editing mode serves that need better than the thing they asked for, and probably closes that issue too.This is the clearest remaining gap against the mainstream Blazor grids. Radzen, Syncfusion and MudBlazor all ship inline and cell editing with validation.
Proposed shape
EditMode—None(default, nothing changes),Row,Cell.EditTemplateper column, falling back to a type-appropriate editor when not supplied.OnRowCommit/OnRowCancel, both cancellable, carrying the edited item.EditContext, soDataAnnotationswork without a second mechanism.Cellmode.What makes this hard
Not the editors. The interactions:
Cellmode needs a cell-level hit target that does not exist yet.Scope
Suggest landing
Rowmode first andCellmode second. Most of the complexity above is cell-specific, and row editing alone covers the common case. Shipping half of this well is better than shipping both badly.Part of the DataGrid sweep — see the plan for ordering against #463, #456 and #412.