DatePickerElement bugged when entering the date by keyboard

[skopz356]

Duplicates

• [X] I have searched the existing issues

Latest version

• [X] I have tested the latest version

Current behavior 😯

First of all thank you for creating this amazing library!

My problem is when I try to write the date by my choice into DatePickerElement by keyboard. The input acts weird, the video shows example when I try to enter date 01/05/2000. I think that the main reason of this behaviour is the weird cursor move.

tadaaa.webm

Thank you for your time!

Expected behavior 🤔

The DatePickerElement should enter 01/05/2000 into the input... same input as I wrote.

Steps to reproduce 🕹

Steps:

1. Go to storybook.
2. Enter date by your choice using keyboard.

[dohomi]

I am currently not able to look into it. But I am happy to check any PR over the weekend. Personally I disable text input on my current apps.

[raphaelfavier]

I'm also experiencing the same issue

[shkreios]

@dohomi @raphaelfavier The problem occurs when using DatepickerElement without a parseDate function, in which case the keyboardInputValue instead of the value parameter is passed to the react-hooks-from controller onChange.

I can open a pull request if you want to change it to use the value, but I don't know if this is the wanted/expected behavior. Reference

[dohomi]

@shkreios PR's are very welcome!

[dohomi]

Hi guys,

I released a v5.10.2 with a new prop to disable text input. I found it very tricky to tackle the date input via keyboard, especially the validation of dates get quite frustrating.

Now you can textReadOnly https://github.com/dohomi/react-hook-form-mui/releases/tag/5.10.2

[Gslaughl]

I'm still having this issue on the latest version, and you can still reproduce it in the Storybook demo.

[dohomi]

@Gslaughl your best bet is using textReadOnly. If you find a solution for this issue feel free to open a PR

[Gslaughl]

@dohomi Oh gotcha, I see that you said that higher up. Until this gets fixed for real, it might be worth documenting somewhere that this feature is broken, or reopening this issue so it gets more attention.

[shkreios]

Hey @dohomi I had another look at the problem, the reason you get is strange behavior is that renderInput will always be called twice & because of these lines when going from an empty input to non-empty the 2 renders have different values. Video: https://user-images.githubusercontent.com/56265022/216606137-f8303ea5-830e-434a-aac1-b510b9030a0a.mov

Was there a specific reason why value is overwritten in these locations DatePickerElement.tsx#L105-L107,DatePickerElement.tsx#L70?

Also @dohomi do you have an example use case for a parseDate? The problem with parseDate is that mutating the input date will not cause the textinput to update and returning a different date object will cause a bad typing experience.

Example

<DatePickerElement
    name="date"
    parseDate={(date) => {
      // check if date is valid
      if (date && !isNaN(date.getTime())) 
      // date-fns will return a new date object
      return setDay(date, 1);
      
      return date;
    }}
    control={control}
  />

In this example, the input will jump from 01/10/3 to 01/01/0003 because as 01/10/3 will be parsed by mui as new Date(3,0,10).

Therfore i think the best option here is to update the props to only allow parseDate only if textReadOnly is true and add a runtime warning.

[shkreios]

If you'd like, I can open another pr to implement these fixes.

Another thing I noticed while trying to debug this error is merging props correctly becomes really cumbersome and can potentially be replaced by something like merge-props.

[dohomi]

@shkreios thanks for your thoughts I will look into it.

[shkreios]

@dohomi Pushed my draft code so you can have a look https://github.com/dohomi/react-hook-form-mui/pull/125

[dohomi]

fixed in v5.14.0