[pickers] Support basic mobile edition on new field components

[flaviendelangle]

Fixes #6214

Preview

Implements @alexfauquette suggestion In onChange, we extract the new value of the active section and since the section is selected, we can take for granted that this section value is the key pressed. We will have to make sure that is works with a Ctrl + V (if the new parsed value is valid and the str value changes more than the active section then we can just set the value to be the new parsed value)

[mui-bot]

These are the results for the performance tests:

Test case	Unit	Min	Max	Median	Mean	σ
Filter 100k rows	ms	484.5	833.7	610.1	670.2	136.555
Sort 100k rows	ms	571.7	996.5	867.4	810.52	148.469
Select 100k rows	ms	181.4	262.3	197.6	212.36	29.944
Deselect 100k rows	ms	130.4	367.8	187.4	212.1	81.06

Generated by :no_entry_sign: dangerJS against 734477e71bf61fa7a14780ce9ec249a7bc389709

[flaviendelangle]

The behavior is not perfect yet but I think it's ok to start the review

[github-actions[bot]]

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

[LukasTy]

A few notes:

• have you looked into the reason why on android the initial focus always jumps to the whole input instead of a clicked section?
• what do you think about adding type="tel" to the input to achieve the same behaviour as with masked pickers (number keyboard)
• delete/backspace situation on mobile is "not the best" 🤔
• honestly, after all this testing and going into an MDN page to test the native input experience is such a relief. I'm starting to doubt the usefulness of out DateField implementation for mobile usage. Simply put, I doubt anyone would want to use the DateField on mobile instead of picker / native date input.

[flaviendelangle]

have you looked into the reason why on android the initial focus always jumps to the whole input instead of a clicked section?

I just saw that the check Olivier made is not working but I don't know why yet. I'll investigate (or if you want to spend some time on it)

what do you think about adding type="tel" to the input to achieve the same behaviour as with masked pickers (number keyboard)

Does it impact what can be rendered ? (for the separator like /). We can have a look, it would be nice to even only open in tel more only when you focus a number section but that might not be doable :laughing:

delete/backspace situation on mobile is "not the best" thinking

Yes, that's something I did not work on yet

honestly, after all this testing and going into an MDN page to test the native input experience is such a relief. I'm starting to doubt the usefulness of out DateField implementation for mobile usage. Simply put, I doubt anyone would want to use the DateField on mobile instead of picker / native date input.

The way I see it, if we can provide an okayish behavior on mobile, it's better than having it totally broken like Telerik. But clearly our doc should say that DateField & co and intended for a desktop usage and that we don't recommend using them for a mobile / responsive application. That for a responsive application, people should use the DatePicker & co and disable the view part on desktop with a prop if they want.

[github-actions[bot]]

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

[github-actions[bot]]

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

[github-actions[bot]]

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

[github-actions[bot]]

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

[flaviendelangle]

Rebased upon #6141 Clean diff added to the PR description

[github-actions[bot]]

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

[joserodolfofreitas]

Considering the numeric keyboard doesn't have arrows, I think we need to automatically trigger "next" if a string of numbers is valid. For example: If the user types '12' or '05' to enter the month, the component immediately moves forward to input the day in a MM/dd/yyyy format.

Is that something feasible to achieve?

[flaviendelangle]

@joserodolfofreitas Didn't we already discuss it several time ? As mentioned on Monday, Telerik dropped this behavior on their last major because it was to much pain to maintain. So that's not something I would implement lightly.

What happens if the user presses 5 in the month ? Does it move ? If it does, then the behavior will not be the same when he presses 1 which can be frustrating.

[alexfauquette]

About the automatic switch to the next section, it could be a topic for another PR. Switching when pressing either '/', ' ', or '-' plus the ability to touche the next section sounds good enough for a first attempt

I don't know if it's related to this PR. but most of the fields (control/uncontrolled demo for example) are buggy. When I press a digit (on desktop) for day or month, it retruns Invalid Date/Invalid Date/Invalid Date

[flaviendelangle]

@alexfauquette Same bug on next, but I'll have a look on this PR since the impacted code moves a lot

[flaviendelangle]

Should be fixed, I'll add tests for the digit editing (which is basically not tested for now)

[joserodolfofreitas]

To be honest, I missed the fact that users can navigate forward with ' ' and '-'. If we could use the '/' (or whichever character used by the user on the date format), that'd be a nice improvement.

[flaviendelangle]

If we could use the '/' (or whichever character used by the user on the date format), that'd be a nice improvement.

You can It could be improved to match the date separator as you said, for now I'm using the 3 most common which cover most of the use cases.

[github-actions[bot]]

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