[docs] Add section for controlled selection and server-side pagination

[DanailH]

Fixes #1782

Updated the docs with the explanation of why the selectionModel might be cleared when new rows are loaded on page change when paginationMode="server".

[flaviendelangle]

and restore it later

Some people will probably struggle to implement it.
Maybe we could also add an example for this part, or just take for granted that appending the rows is the way we want to encourage.

[DanailH]

I'm opened to suggestions here. It's unclear what the desired behaviour should be. For me, the way it is looks correct but so does the initial implementation in the ticket (not appending the rows). Because the selection is controlled the only solution I can see is either to leave it as it is or prevent the grid from cleaning up the selectionModel if the rows are missing.

[flaviendelangle]

I guess we can start by explaining only the row-concatenation as you did
And if we have feedback asking for the selection-restoration approach, add another dedicated example later on.

[DanailH]

We should probably also take this #2602 (comment) into consideration. If we want to fix that as well we will need to change the way the selectionModel behaves as the Select All feature is not really server-side friendly at the moment.

[flaviendelangle]

Indeed

[rjv]

append the newly loaded grid rows to the existing rows

Doesn't this break the functionality of the "select all" checkbox in the grid header? Using this demo, try the following:

1. Let the data for page 1 load
2. Browse to page 2
3. Click the "select all" checkbox in the grid header
4. Observe that there are 10 rows selected and not the expected 5

[DanailH]

append the newly loaded grid rows to the existing rows

Doesn't this break the functionality of the "select all" checkbox in the grid header? Using this demo, try the following:

1. Let the data for page 1 load
2. Browse to page 2
3. Click the "select all" checkbox in the grid header
4. Observe that there are 10 rows selected and not the expected 5

This is how the Select All feature works when the pagination is client-side.

[rjv]

This is how the Select All feature works when the pagination is client-side.

The client-side mode will select every row. It will not do this for server-side; it'll only select the rows that have been downloaded.

It feels unintuitive and somewhat misleading for the paginationMode="server" use case. Having elements from rows hidden only because of the page size is a work-around at best because the table will only ever have a subset of the data that was queried for (unless the user literally paged through every page). This introduces another gotcha that I think developers should at least be made aware of, especially if you're making an "official" recommendation in the docs.

[m4theushw]

We could add a note in https://mui.com/components/data-grid/pagination/#server-side-pagination linking to the new section.

[DanailH]

@m4theushw @flaviendelangle if we agree to investigate the select all issue in a separate PR should we proceed with merging this one?

[flaviendelangle]

@m4theushw @flaviendelangle if we agree to investigate the select all issue in a separate PR should we proceed with merging this one?

@DanailH the select all issue is not caused by this PR so no problem for fixing it on a following one.

I take a last look at the texts of this PR and I approve 👍

[m4theushw]

if we agree to investigate the select all issue in a separate PR should we proceed with merging this one?

The Select All issue is because we're appending rows. If the user change the page a bunch of times and later he select all rows, the number of selected rows will be the total count. The workaround is not good to be a "official" solution.

We could explore the first solution for the docs. It requires a setTimeout, which also not good, but it works: https://codesandbox.io/s/controlledselectionserverpaginationgrid-material-demo-forked-y247k?file=/demo.js

CX9ndMSAEX.mp4

---

About the definitive solution to be done in another PR. I think we should allow to have non-existing IDs in the selectionModel prop. Since it's controlled by the user, he could send any value. We should sanitize the value in our side. I had a similar problem where some row could be selected and later the isRowSelectable changes making the previously selected row unselectable now. The solution I used was to filter the selected rows in every place it's used.

https://github.com/mui-org/material-ui-x/blob/68ae5d5d477500ba56564df10a215eb7ad2e22d9/packages/grid/_modules_/grid/components/columnSelection/GridHeaderCheckbox.tsx#L41

[rjv]

I devised a crude work-around that attempts to fix the issue of "select all" selecting more than the current page by using isRowSelectable: https://codesandbox.io/s/material-demo-forked-f0mxc?file=/demo.tsx. Still thinking through edge cases but it's a working premise.

It doesn't automatically select rows on any new pages that user hasn't already browsed, so I'd have to keep track of an "all selected" state independent of the data grid and trigger apiRef.current.selectRows(apiRef.current.getAllRowIds()) after new data loads.

[DanailH]

For now, we can go with the option @m4theushw proposed (with saving the selectionModel on page change and then restoring it). Both options are listed as potential solutions, although they behave differently. Either way, a fix for this will be provided in a separate PR.

[oliviertassinari]

Two feedback on this one. A sentence should have a closing dot. "here" is considered to be avoided as link description: https://www.w3.org/QA/Tips/noClickHere. Maybe?

Suggested change

	**Note**: For more information regarding server-side pagination in combination with controlled selection check [here](/components/data-grid/selection/#usage-with-server-side-pagination)
	**Note**: For more information regarding server-side pagination in combination with controlled selection check [the dedicated section](/components/data-grid/selection/#usage-with-server-side-pagination).