Add new DateRange component

[rllina]

Is your feature request related to a problem? If so, please describe.

The existing DateRange component is clunky and requires complex code to manage state and styling, when using both the date and time pickers. Because of this, CN1 has defaulted to using the built-in input of type datetime-local, which looks like this:

This input is mostly sufficient for our needs, but does depend on the usage of Chrome.

We would like to port MaterialUI's Date Time Range Picker to NDS, as a V2 of the existing DateRange component with the following acceptance criteria:

• State can be managed directly - and is controlled via datetime vs dates and times separately
• Styling does not require weird workarounds like this: eco example
• [Nice to have] The component's localization can be managed via props

Is your team blocked from moving forward by the lack of this functionality/behaviour?

No, this is just a nice-to-have.

Do you have an alternative solution for the problem?

CN1 is currently using the datetime-local input, example here.

• The calendar "picker" does not show up in any non-chromium browsers like Firefox.
• It is not possible to set the localization of the component, it will always be set to the User's local time. It would be nice if we could control this and set it to UTC.

Have you consulted and have an alignment with the product designer?

• Yes
• No

Who would you like to execute this feature?

• Myself
• DesignOps

When do you need this by?

No timeframe

Helpful resources

No response

Additional context

CN1 ticket for this issue: https://nulogy-go.atlassian.net/browse/CN1-3783

[haideralsh]

Hey @rllina one of CN requests in the past was using seconds with the DateTime picker/range. Do you know if MUI's component allows for that?

If not, I think we can fix our Date range selector styling and allow it to work with DateTime vs. date and time. I have concerns about porting MUI's DateTime picker, as it appears to be a complex component with numerous customization options, which could present significant challenges.

Given that usage of the DateTime Range is quite niche and that NDS wants to remain lean and opinionated, it might not be the best fit.

I am open to discuss more and see what the best option would be.

[rllina]

@haideralsh yeah the MUI component allows for seconds, I believe.

The main issue with using the current NDS date range component is with state management. It's really tricky to manage the from and to ranges, especially with seconds, when you need 4 different states (from date, from time, to date, to time) and I can't access the values directly in order to retrieve and send them as a form. This is the main reason why we opted to use the built-in input component, and why we think the NDS component is too clunky for our needs.

Here is an example of code we had in place to get it working before we converted: link

I definitely agree with you about MUI being too complex, but would still like to see improvements to the usability of the date range component, if possible.

[haideralsh]

@rllina I see, that makes sense and I think our DatePicker could use some improvements. All our date pickers in NDS use the reactdatepicker.com/ component, which supports:

• Using a JS Date object for both date and time
• Attached time selector to date selector
• Granular time selection
• Already an NDS dependency with configured styles

Screen.Recording.2024-05-21.at.3.36.42.PM.mov

Do you think adapting react-datepicker can address your use case?

[yusaira-khan]

@haideralsh the time picker in reactdatepicker.com is too limited for our use case. we need functionality like https://mui.com/x/react-date-pickers/date-time-picker/

Time picker in suggested library:

Required Time picker functionality: