[data grid] Support edit functionality with server-side data source

[MBilalShafi]

The server-side data source would accept an optional parameter updateRow which would be used to persist the edited rows on the back end.

Feel free to upvote to see this feature land faster.

[ptuukkan]

Hi @MBilalShafi,
I am looking for an update or a rough estimate for this.

We are using data source with tree data with Apollo client, without data source cache. We are looking to implement some edit functionality to some cells. Using the edit mode and processRowUpdate seems to work for normal and parent rows but updating child rows seem to lose their status as a child row and move them to the end of the grid.

We also tried not using edit cells and just fire a mutation directly from the renderCell but then calling updateRows ended up in the same result which makes sense because processRowUpdate calls updateRows under the hood. Workaround(ish) here was to not use updateRows but to just refetch rows using unstable_dataSource.fetchRows from apollo's cache. This collapses the children but they stay there at least. We could probably write some code to handle that though.

We would really like to use edit cells though so my question is are you aware of a workaround we could use here with edit cells and processRowUpdate?

Best regards,
Pekka
Premium customer - Support ID: 99756

[ptuukkan]

I was curious about how would this be implemented so I went and read some of the code related to this. It does not seem too difficult to implement and I might be able to contribute this.

I'm thinking that in useGridCellEditing and useGridRowEditing we have to check if we have enabled dataSource and then where we would use processRowUpdate we call some new dataSource api instead. The new dataSource api would then call the user supplemented updateRow prop and then call the private api function updateServerRows with the result. We probably need to also have new error handling similar to onProcessRowUpdateError.

Updating the data source cache seems a bit difficult though. Obviously easiest would be to just clear it after a row update, but I don't know if that is acceptable here. If we were to improve the data source cache so that all the rows are in a separate data structure and the GridGetRowsParams cache keys reference to a set of rows it would be easy enough to update or delete one row without clearing the current cache.

But let me know what you think and if I'm completely wrong about this. Would be fun to do some open source!

[sparksm]

Hi @MBilalShafi,
We are also looking for an update on this. We want to use grouping and inline editing from server data and experience an issue where the updated row is rendered outside the groups like this example.

Thanks in advance.

Premium customer - Support ID: 102668

[MBilalShafi]

Hi @ptuukkan,

Apologies for the delayed response.

We would really like to use edit cells though so my question is are you aware of a workaround we could use here with edit cells and `processRowUpdate?

I'd love to take a look at this and provide a workaround. Could you prepare a minimal reproduction of the current implementation that you have that portrays the challenges you mentioned? It will be helpful in pin-pointing the specific pain points and suggesting a possible solution.

I'm thinking that in useGridCellEditing and useGridRowEditing we have to check if we have enabled dataSource and then where we would use processRowUpdate we call some new dataSource api instead. The new dataSource api would then call the user supplemented updateRow prop and then call the private api function updateServerRows with the result. We probably need to also have new error handling similar to onProcessRowUpdateError.

Updating the data source cache seems a bit difficult though. Obviously easiest would be to just clear it after a row update, but I don't know if that is acceptable here. If we were to improve the data source cache so that all the rows are in a separate data structure and the GridGetRowsParams cache keys reference to a set of rows it would be easy enough to update or delete one row without clearing the current cache.

But let me know what you think and if I'm completely wrong about this. Would be fun to do some open source!

Correct, one of the main challenges is around the proper cache mutation and making the row updates stable and aligned with the backend server.

Regarding your query, we always appreciate community contributions. Feel free to shoot a PR or reach out if you have any questions.

In any case, it's already one of the top priorities for the team atm, see the answer regarding an ETA below. 👇

We are also looking for an update on this. We want to use grouping and inline editing from server data and experience an issue where the updated row is rendered outside the groups like this example.

@sparksm Thank you for reaching out.
This feature is one of the top priorities for the team for Q4 2024 and Q1 2025. The initial work has been started already and you should soon see an initial PR.

Let me know if you have further questions or suggestions on the DX of the feature.

[ptuukkan]

Thanks for the response @MBilalShafi.

I'd love to take a look at this and provide a workaround. Could you prepare a minimal reproduction of the current implementation that you have that portrays the challenges you mentioned? It will be helpful in pin-pointing the specific pain points and suggesting a possible solution.

We have the exact same problem as @sparksm. So you can see it in the sandbox they provided. When doing an update for a child row, it loses its status as a child node and is moved to the bottom of the grid.

We have moved away from data source for now so a workaround is not crucial at this point. Once the server side editing is shipped we will most likely go back to using data source.

@sparksm Thank you for reaching out. This feature is one of the top priorities for the team for Q4 2024 and Q1 2025. The initial work has been started already and you should soon see an initial PR.

Awesome! Then I will let you pros handle it and not get in the way. I'll keep an eye out for it and test it as soon as possible 💪

[boonya]

For your information, guys.

While looking on a workaround, I have noticed that there is a function updateServerRows. I tried to use it instead of updateRows and it the issue disappear. A lot of questions still over there:

• How stable this API is, because it is undocumented and marked as internal.

import {useGridPrivateApiContext} from '@mui/x-data-grid/internals';

const gridPrivateApi = useGridPrivateApiContext();

gridPrivateApi.current.updateServerRows([{/*** row object to be updated */}], groupKeys);

• How use updateServerRows API under the hood of processRowUpdate API.

  • mui-x/packages/x-data-grid/src/hooks/features/editing/useGridCellEditing.ts

    Line 452 in e38e018

    apiRef.current.updateRows([finalRowUpdate]);

  • mui-x/packages/x-data-grid/src/hooks/features/editing/useGridCellEditing.ts

    Line 460 in e38e018

    apiRef.current.updateRows([rowUpdate]);