[core] Simplify isPrintableKey logic

[mnajdova]

Related to #4687

I need this for fixing the build-in mui/material-ui#33196

Before
https://62b570c40e29bd000905cd20--material-ui-x.netlify.app/x/react-data-grid/editing/#making-a-column-editable
https://62b570c40e29bd000905cd20--material-ui-x.netlify.app/x/react-data-grid/#mit-version

After
https://deploy-preview-5414--material-ui-x.netlify.app/x/react-data-grid/editing/#making-a-column-editable
https://deploy-preview-5414--material-ui-x.netlify.app/x/react-data-grid/#mit-version

[mui-bot]

These are the results for the performance tests:

Test case	Unit	Min	Max	Median	Mean	σ
Filter 100k rows	ms	247.7	531.9	389	365.14	104.292
Sort 100k rows	ms	455	859.5	776.8	709.18	153.574
Select 100k rows	ms	108.1	252.1	193.4	186.58	46.018
Deselect 100k rows	ms	108.9	185	139.2	148.4	29.335

Generated by 🚫 dangerJS against 9c4bfec

[oliviertassinari]

It could be great to add a test case for this. It's the second time we iterate on the logic to fix a bug. The first time was in #1409. We also fix the logic with, say when typing "$12" into the cell.

[mnajdova]

It could be great to add a test case for this. It's the second time we iterate on the logic to fix a bug. The first time was in #1409. We also fix the logic with, say when typing "$12" into the cell.

Sure, makes sense. I was looking a bit at the test in cellEditing.DataGridPro.new.test.tsx, but looks like the test used directly the apiRef.current.startCellEditMode API. I may not have much context, but I was expecting that the tests would focus on the cell, simulate some key-down and validate that the editing has started. I am not sure where/what exactly the test should test out.

[flaviendelangle]

Feel free to open another PR for the test
I'm merging to unlock you in this release 👍

[mnajdova]

Feel free to open another PR for the test
I'm merging to unlock you in this release 👍

Thanks @flaviendelangle

[m4theushw]

Sure, makes sense. I was looking a bit at the test in cellEditing.DataGridPro.new.test.tsx, but looks like the test used directly the apiRef.current.startCellEditMode API. I may not have much context, but I was expecting that the tests would focus on the cell, simulate some key-down and validate that the editing has started. I am not sure where/what exactly the test should test out.

This test file is divided into groups whose tests inside reproduce how the user would interact with the editing functionality. The first group is apiRef and it contains only tests checking the methods from the editing API. Here we test the behavior of apiRef.current.startCellEditMode, for example. It might be controversy to call API methods here but they're part of the public API, so users can call them directly. The group start edit mode is where we have tests simulating user interactions (e.g. keydown). Since we're already tested what the API methods do in the previous group, here we only check that they are called with the right params. Inside this group there're different groups equivalent to the different ways that users can interact with the API, e.g. by double-click, by pressing Enter, by pressing a printable character and so on.

The new test could be inside

mui-x/packages/grid/x-data-grid-pro/src/tests/cellEditing.DataGridPro.new.test.tsx

Lines 586 to 587 in 21c1f6c

	describe('by pressing Enter', () => {
	it(`should publish 'cellEditStart' with reason=enterKeyDown`, () => {