[DataGridPro] Always export the pageSize and page when it has been initialized or is being controlled

[flaviendelangle]

Fix #3905

[mui-bot]

These are the results for the performance tests:

Test case	Unit	Min	Max	Median	Mean	σ
Filter 100k rows	ms	225.9	440.7	414.3	355.66	90.794
Sort 100k rows	ms	483	894.1	745.2	728.92	136.741
Select 100k rows	ms	152.1	210.1	204.3	195.08	21.786
Deselect 100k rows	ms	104	277.2	193	180.64	60.744

Generated by 🚫 dangerJS against 2778739

[alexfauquette]

Sounds good to correct the bug

I'm wondering why the other states do not need the same modification. For example the column pinning could be:

• start with an initial state in which there is a pinned column on the left
• user don't like pinned column, she removes it
• the state export returns nothing because pinnedColumnsToExport.left.length === 0 && pinnedColumnsToExport.right === true
• she reopen the page, the pinned column is back 🙀

Why not exporting all the restorable state without caring if values are the default one or not. You provide all the data to the user. If it is for performances reasons, it could be done in the restore

[flaviendelangle]

It was a proposal of @m4theushw
The goal was to avoid breaking changes if we change our default value (see #3593 (review))

Maybe we could apply the logic of this PR to the other exportable states and only strip the default value if it's not being neither controlled nor initialized by the user.

[alexfauquette]

Yes, that would be a solution

I'm not sure to understand the breaking change you want to avoid, here is what I get:

If we change the default value of the DataGrid on a property that respects all the following properties

• not controlled by dev
• not defined in initialState by dev
• not modified by end-user

Then the end-user should see the grid with the new default prop.

Is that the reason for not exporting all the substates by default?

[flaviendelangle]

Yes exactly

[m4theushw]

First I proposed to not export default values to keep the exported data as small as possible to be serializable and stored in a database. Regarding the example given with column pinning, it may be a problem but we can add a prop to control the behavior if users ask. Currently, we do a "soft" restore, where we try to merge the current state with the one being restored. This prop once enabled would do a "hard" restore by first resetting the state, then restoring it. A similar problem, but with the column widths, I pointed in #3816 (comment). The idea that exporting default values could cause a breaking change it because developers could have old values (e.g. page size) still stored in a database, then we change the default page size but users don't see it in effect because the old value is restored.

[alexfauquette]

Ok, keeping size small make sense, but the rules to know what must be exported will probably be complicated to explain to users

I propose to merge this PR and see when we will have users feedbacks

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.