DatePicker: date clears after an invalid character is added to valid date

[silvalaura]

Describe the bug For https://github.com/cengage/react-magma/issues/1269, we fixed Date disappears if user enters a valid date, then changes it to an invalid date. Now the issue is that if a valid date is on the input and a random other character gets added, the date disappears again.

To Reproduce Steps to reproduce the behavior:

1. Go to https://next--upbeat-sinoussi-f675aa.netlify.app/api/date-pickers/
2. Click on a date picker and select a valid date
3. Add another character to the field
4. Notice the date has been cleared

Expected behavior

• Date does not get cleared
• The date will remain in the input and there will be validation to ask the user to enter a valid date

[silvalaura]

This could be made easier with masking: https://github.com/cengage/react-magma/issues/1157

edit: not necessarily; when we build masking functionality, we will also have the ability to turn it off so we need solutions for masking and without masking.

[silvalaura]

This ticket needs further refinement. Notes so far:

What other systems do:

• MUI does not have this problem because they use masking for all date pickers (example)
• Atlassian also seems to clear some times (example), other time it defaults to the current date.
• US Gov never clears and does not mask (example)
• Carbon behaves the same way as current Magma in their Single with Calendar example (clears), but does not clear in their Simple example. What I did notice about Carbon is that they handle their dates in a smarter way than we do: -- In https://react.carbondesignsystem.com/?path=/story/components-datepicker--single-with-calendar: --- If I enter 01/24/2025gdfsgdfg, it knows to trim the excess characters and goes back to 01/24/2025 --- If I enter 01/18gdfgdfg/2025, it falls back to 01/01/2025 --- If I enter 02/0154/2025 OR 02/56/2025, it falls back to 02/01/2025 --- If I enter 01/16/20256576, the date gets cleared

Thoughts It seems that clearing a date when it is invalid is not actually a terrible thing to do.

I think what we need to do is improve how we communicate with adopters when dates entered are invalid (wrong format? have letters?), and also improve how smart our date processing is (i.e can we trim characters after XX/XX/XXXX?). Having an onReset (#1523) function may go hand in hand with this.

We need to consider not introducing a breaking change here as our date pickers are used by a lot of consumers.