[DataGrid] Experiment: Remove layout jump when start editing

[MBilalShafi]

• [x] I have followed (at least) the PR section of the contributing guide.

Fixes #5513

Preview: https://deploy-preview-9612--material-ui-x.netlify.app/x/react-data-grid/

[mui-bot]

Netlify deploy preview

Netlify deploy preview: https://deploy-preview-9612--material-ui-x.netlify.app/

Updated pages

No updates.

These are the results for the performance tests:

Test case	Unit	Min	Max	Median	Mean	σ
Filter 100k rows	ms	315	556.3	358.4	410.98	88.512
Sort 100k rows	ms	640.4	1,022.1	816.1	879.26	139.314
Select 100k rows	ms	209.3	308.7	276.7	265.36	39.406
Deselect 100k rows	ms	151.5	388.5	226.4	248.14	78.803

Generated by :no_entry_sign: dangerJS against 1e7083056f6d2ab5f45955e90a182266fb322434

[oliviertassinari]

To see with the designer if this doesn't surface another issue: the lack of style difference between the edit mode and non-edit mode. Both mode looks almost the same after fixing the layout shift.

[gerdadesign]

Thanks! One quick note is that numbers are still jumping to left alignment.

On the stylistic side, I think we have some inconsistencies on elevation level that may be what @oliviertassinari is picking up on?

Consider that currently in light mode, we have a blue focus ring + elevation shadow to show that a cell is active and editable. We're using elevation ~1~ 2 for the editing cell. See below for the screenshot of differences between keyboard/mouse navigation of the editable vs non-editable cells, and how these fields interact with the hover style of the row.

Currently, in dark mode, we have a focus ring indicator, but we do not have an elevation indicator. Below screenshot illustrates the same navigation. Note that these are on the Material Design default background of #121212.

And finally, you can see this lack of elevation more clearly on our navy blue background in the docs:

Because in dark mode, the hover style visually appears the same as elevation level 3, here is a mockup with setting the editable cell with an elevation background of 6 (so that there's more contrast).

Which means this is what it would look like on the docs with a navy blue background:

But we've discussed this problem before where some elements have the Material #121212 background + elevation overlay. So if we correct for that and allow the overlay to sit on top of whatever color background, it should look like this:

Furthermore, because dark mode is now requiring a higher elevation level of 6, this is what it might look like if we made light mode consistent with an elevation of 6 instead of 1:

This is all laid out in this figma file, but happy to add a loom walkthrough if this is unclear.

It also opens up the question of whether the row hover style should update regardless of navigation by mouse or keyboard or if we should do something else specifically for keyboard navigation? Currently, you could have used your mouse to hover, but as soon as you switch to keyboard, your hover state is "stuck". Is this the intention?

[MBilalShafi]

Thanks @gerdadesign for the research and doing all the comparisons in the Figma. I think what we currently have is the elevation = 2 according to this table.

Is the intention to set the contrasting background color in dark mode? Can we do that without changing the elevation level, as it's applied separately anyways. What do you think? I am saying so because to me personally, the elevation level 6 looks a bit exaggerated. (Its my personal observation and you may have a different one)

We also have an idea from @oliviertassinari to make it the edit field pop a bit on edit state (like notion) which seems a decent UX too while doing cell editing, I am just curious how will it play with row editing if we apply the same popping to the row (just like we apply the same elevation to the row that is editing). Though IMO, increasing the outline width could be a another way to differentiate between normal and edit modes?

It also opens up the question of whether the row hover style should update regardless of navigation by mouse or keyboard or if we should do something else specifically for keyboard navigation

Hmm, good point. As per my understanding, the hover background is associated specifically with the mouse hover. On keyboard navigation, the cell outline moving from cell to cell would be a sufficient pointer for me to be aware of the cell focus shift. I observed the same with other grids like AgGrid for example.

numbers are still jumping to left alignment.

Yes, that's because we chose right alignment for displaying the numbers and for edit it works as normal edit field i.e with left alignment (I honestly don't know the motivation behind that as I've seen some other grids not follow this pattern), we can possibly treat it separately if we want to change this behavior?

[github-actions[bot]]

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