[DataGrid] Implement Row editing

[oliviertassinari]

Benchmark

• https://ant.design/components/table/#components-table-demo-edit-row
• https://material-table.com/#/docs/features/editable
• https://demos.telerik.com/kendo-ui/grid/editing
• https://www.telerik.com/kendo-react-ui/components/grid/editing/
• https://ej2.syncfusion.com/react/demos/#/material/grid/normal-edit
• https://editor.datatables.net/

[cq-ubaid-khan]

Is there any way to perform row editing with Data Grid manually?

[DanailH]

@cq-ubaid-khan Until the data grid comes with built-in support, you may be able to achieve this functionality manually. You can render your own custom component in a cell so you can add input and try to implement the feature. You can check the docs here https://material-ui.com/components/data-grid/rendering/

[cq-ubaid-khan]

@cq-ubaid-khan you may be able to achieve this functionality manually. You can render your own custom component in a cell so you can add input and try to implement the feature. You can check the docs here https://material-ui.com/components/data-grid/rendering/

Hmm. Well, I am doing the same you said with Material Table, but it's not that flexible, and switching to DataGrid for doing the same would not make difference. Waiting for the feature to be implemented by the Material UI team.

Thanks.

[ctackett-work]

I emailed the contact email and was told to ask here - I was just curious if there's an estimated release date/month/timeframe for the editing rows feature in DataGrid?

[oliviertassinari]

@ctackett-work We are currently focusing on the cell edit feature #203. The row edit feature wasn't prioritized yet. I think that the last time we talk about it we said we would wait for #203 to be adopted by the community, waiting for potential fundamental flaws to be reported and fixed before building more advanced features on top of it. Basically, first, make sure that cell edit is a sane foundation (battle test it enough) to then build row edit on top of.

So, it seems that the short answer is: cell edit soon, once released, you can build row edit on your own. Row edit, not anytime soon.

[arheinjohnson]

Any update on timeline for this feature?

[oliviertassinari]

@arheinjohnson We have recently released the cell editing feature. Does it solve your problem?

[arheinjohnson]

@oliviertassinari thanks for your response, we are aware of the cell editing feature and are implementing custom edit cells. In this case I was specifically asking about the edit row feature.

[m4theushw]

I'm in a dilemma about what outcome we want to achieve here. In most of the examples, editing a row means turning all cells in edit mode. To do the same we will have to modify the cell editing feature to not publish some events and also change a few API methods to only work in the cell editing mode, it's almost like to have a cell editing API and a row editing API. Is that what we're looking for? A simpler solution would be to patch the current cell editing to allow to edit multiple cells at the same time and only commit when the user clicks outside the row. That would be easier for us but I don't think developers want that. Although, the first approach is better but it makes the API more complex. I started to explore the first approach, here's what I already have (the shadows are not good, I'll fix later):

[oliviertassinari]

it's almost like to have a cell editing API and a row editing API.

@m4theushw This makes a lot of sense for me. I don't think that we should try too hard to unify them. We had a design session a while ago in #1032. We didn't talk too much about row editing.

Looking at the benchmark, it seems that row edit often comes with a batching mode. I mean, end-users usually have to click a button to validate or cancel their changes. Maybe we should make this happen with #517.

[m4theushw]

I mean, end-users usually have to click a button to validate or cancel their changes.

This is indifferent to me, we could commit with a click outside the row or through an external button. Syncfusion's example allows both.

I started to draft the API we could expose for the row editing:

• A new prop editMode?: 'row' | 'cell'; to force the behavior for the whole data grid.
• setRowMode(id, 'edit') create an entry in the editRows state with the value of all fields
• setRowMode(id, 'view') removes the entry in editRows state added above, used to revert the values or after commit
• getRowMode(id) determines if the row is in edit or view mode
• setEditCellProps(params) updates the props in editRows for the given field and id, it's shared with the cell editing
• commitRowChange(id) applies the values saved in editRows to the row, similar to commitCellChange but row-wise
• GRID_ROW_EDIT_EXIT is published when the user clicks outside the row, used to discard the changes in a row
• GRID_ROW_EDIT_COMMIT is published when there's no error in no field, we're about to apply the state to the row

While that, the cell editing API (during the row editing) would behave in the following way:

• setCellMode and commitCellChange will throw an error if called
• GRID_CELL_EDIT_ENTER and GRID_CELL_EDIT_EXIT won't be published because there's no concept of edit mode in row editing

We could split these two APIs into separate hooks. If you look into https://github.com/mui-org/material-ui-x/pull/2098/files?file-filters%5B%5D=.ts&file-filters%5B%5D=.tsx#diff-b58ef2608987589ff71f621df6cc9458c607e9b080c9a2c9be7dcaf920539f67 it's beginning to become cluttered with logic that only runs in row or cell editing.

[flaviendelangle]

> startEditingRow(id) removes the entry in editRows state added above, used to revert the values or after commit

I think you meant stopEditingRow(id) or something similar.

We could split these two APIs into separate hooks.

It would indeed be better for the overall readability

The API makes sense to me.

[oliviertassinari]

@m4theushw I have updated #204 (comment) to mention the new editMode prop.