refactor(date-selector): Refactor DateSelector component

[diogomateus]

What this PR does

This PR refactors the date selector component to have 3 text inputs instead of 3 select inputs.
By setting 3 inputs it means that keyboard/typing navigation also needs some custom adjustments:

• when reaching the end of input, focus changes to next input:
  

• when using right/left arrows, it is possible to navigate to next/previous inputs (like tab and shit+tab). if there is a value already, input value is selected
  

• backspace, if current focused input is empty, goes to previous input:
  

• if day is 4 or more focus changes to month input, if month is 2 or more focus changes to year input:
  

How to test?

Test visiting the story:
http://localhost:9009/?path=/docs/jsx-dateselector--date-selector-story

Before:

After:

Checklist:

• I reviewed my own code
• The changes align with the designs I received
  Or give a reason why this does not apply:
• I have attached screenshot(s), video(s) or gif(s) showing that the solution is working as expected
  Or give a reason why this does not apply:
• I have updated the task(s) status on Linear
• All new media is optimized (images, gifs, videos)

Browser support

My code works in the following browsers:

• Firefox
• Chrome
• Safari
• Edge

[busypeoples]

Two things I noticed: You could set a min of 1 and max of 12 for the month. Also if the year is invalid, you could highlight only the year as wrong so it is clear where the error is.

Another question: this will break all our end to end tests?

[diogomateus]

Two things I noticed: You could set a min of 1 and max of 12 for the month. Also if the year is invalid, you could highlight only the year as wrong so it is clear where the error is.

Another question: this will break all our end to end tests?

@busypeoples Added the year only validation.
And answering your questions:

• For the min/max, I'm not using that because it needs input to be a number which would break some input selection features that needs to be added (you can view those on the above gif screenshots),
• Regarding the e2e tests it will break but I've already updated them on a PR on app - it's mostly about replacing .select('May') with .type('5').

[talo242]

Works pretty well!

I'm requesting changes mostly to use the input labels instead of the data-testid.

[talo242]

It seems like we are not checking if dateFormat is a valid date until the component performs an update.

Do you think we could fail earlier?
E.g. throw and exception during development if the dateFormat is incorrect.

[talo242]

To make sure we are not impacting accessibility, IMHO it'd be better if we stick to the actual input labels, and not rely on data-testid.

Is there a reason to use data-testid to target these inputs?

[talo242]

How can we use this as uncontrolled component?

To give you more context, on the task engine we are adding a specific name and id to each input.
For example, a text input would have an id like this: input-f8556724-a703-455e-a6f5-16b0d16bb26d

But for the date input, we want the full date, so we are doing a tiny hack by using a hidden field with the full date.

I'm wondering if we should have such hidden field already inside the component instead of the individual name for each input.

Happy to discuss this a bit further. We don't need to change anything for this PR.

[talo242]

Are we not allowing this to be configured via props?