[data-grid] Keep newly created row in viewport

[Maia313]

Order ID 💳

#37886

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

The problem in depth 🔍

Inline editing, which can be seen in the example control-with-external-buttons

When sorting rows by name, and after that a new record is added, depending on the name, the row would end up either on top, in the middle or at the bottom of the list. It is inconvenient to have to see the row disappear out of view (if user keeps looking at the top section of the table), immediately after being added. Is it possible to prevent that from happening and instead always add the new row at the top?

At the same time, when pagination is added the row ends up at the bottom of the list (on page 4 for example, when user is still looking at page nr 1) so user doesn’t really get to see the row being added. Do you have a solution for that?

Similar issues

• Prevent re sort after cell edit  #6261

Your environment 🌎

`npx @mui/envinfo`

  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.

[flaviendelangle]

@m4theushw

I would be curious to see how other grids handle this topic.
Leaving the row on top feels wrong to me because it makes the sorting wrong.
A dirty solution on your side would be to remove the sorting model and update to rows in the order they currently have when you start creating a row.

You can also scroll to the newly created row. Without pagination it's easy, with pagination you would first need to go to the right page, which can be tricky in some scenarios (especially with variable row height)
Not directly related to this issue, but @DanailH maybe a new getRowPage(id) would be interesting to avoid having users looking at the row metas.

[m4theushw]

Leaving the row on top feels wrong to me because it makes the sorting wrong.

It turns out that this is what other grids do. For instance, AG Grid doesn't re-sorts the rows after changing the value of a cell from a sorted column.

To implement this in the DataGrid it wouldn't be very complex. In apiRef.current.updateRows we only need to pass a reason to the rowsSet event so the sorting can ignore if the rows change was caused by editing a cell.

[flaviendelangle]

The AG Grid page regarding this topic: https://www.ag-grid.com/javascript-data-grid/change-detection/#change-detection-and-sorting-filtering-grouping

We can ignore the sorting / filtering / grouping update (probably harder to achieve for grouping) when the update comes from editing.
But in that case we should provide an equivalent to there applyTransaction to avoir having users manually triggering internal methods.

[DanailH]

Not directly related to this issue, but @DanailH maybe a new getRowPage(id) would be interesting to avoid having users looking at the row metas.

@flaviendelangle interesting, if we are to add this method will it only return a value different from 1 when there is pagination?

[flaviendelangle]

Different from 0 I suppose (the pagination being 0-based)

But yes, I think that if the pagination is disabled, we could early return a 0.

[m4theushw]

But in that case we should provide an equivalent to there applyTransaction to avoir having users manually triggering internal methods.

Our equivalent is updateRows. I didn't understand what you meant by "manually triggering internal methods".

updateRows publishes rowsSet at the end, which triggers the filtering and sorting:

mui-x/packages/grid/x-data-grid/src/hooks/features/filter/useGridFilter.tsx

Line 322 in f80cd89

useGridApiEventHandler(apiRef, GridEvents.rowsSet, apiRef.current.unstable_applyFilters);

My idea was to have a param in updateRows telling if the filtering and sorting should be reapplied. This param would turn into a reason that the listeners (e.g. above) check before running.

[flaviendelangle]

For me in AG Grid, handles the rows in a very different way that we do.
Because when committing an editing value, they don't automatically call applyTransaction, but the aggregated values are updated. So I guess they have 2 internal states for the rows

• One for filtering / sorting
• One for rendering / aggregation
  And applyTransaction updates the 1st one, the 2nd one being updated automatically when committing and editing value.

In this example, they say to the user to manually do onCellValueChanged: newData => applyTransaction(newData)

So as far as I understand, they still have 1 call to applyTransaction = 1 recomputation of sorting, filtering and grouping.

If we add a param on updateRows to say "apply sorting / filtering and grouping or not".
Then I think we need to expose a new method to re-run the whole row sorting, filtering and grouping.