Date Picker and Time Picker: Component Release Update

[nkrantz]

Date Picker and Time Picker

These two components are on our roadmap for the June 1, 2021 release. Because building them from scratch will be a big lift, both engineering- and design-wise, we decided to first release them as Stage 1 components, built on top of the HTML Input element using type="date" and type="time". This decision means that the components will be consumer-ready before we're able to put in the time required for a custom build. It also means, however, that we need to consider certain functionality and restraints included with the HTML pickers. We don't have any control over how browsers implement the components, so we did cross-browser testing to ensure that all Twilio customers would have positive experiences using the pickers. The kickoff and explorations were used to determine what the API would look like, planning ahead to avoid any potential breaking changes with our custom pickers.

Component Kickoff

The kickoff was used to make decisions on outstanding questions such as which variants to include (date, time, datetime), how to account for certain Twilio use cases (date range picker, pre-defined range options), and how to best support all browsers. The DSYS team decided to release a Date Picker and a Time Picker, leaving the DateTime Picker out of scope for the current release. In order to accommodate existing use cases across Console and SendGrid, we decided to provide examples and guidance in the documentation.

Next Step: RFC - API Exploration

Until recently, Safari didn't support the HTML date and time pickers, prompting a discussion about whether to use Help Text and/or placeholders to display desired input for those users. There was no clear path forward after the kickoff meeting, so we decided to have an API Exploration RFC, where we presented options to the DSYS Committee for feedback. During the meeting, we discovered that Safari had fixed their <input type="date" /> and <input type="time" /> implementations, making our decision a whole lot easier. The only other topic presented during the meeting was date format implementation. The SendGrid Date Picker provides a dateFormat prop, so we had two options: copying SendGrid and using a prop, or exporting a dateFormatter function that consumers can use with their onChange handlers. The Committee thought that using a function would be more consistent with other component usage, and give more flexibility to the consumer. This decision will also allow us to add formatting props to future updates without any breaking changes.

Outcomes and Options

Although we no longer had to worry about Safari users' experiences, there were still some decisions yet to be made. There are three DOM methods included with the HTML elements (select(), stepUp() and stepDown()) that our consumers will be able to make use of when implementing the Paste Date Picker and Time Picker. Because we're planning on building custom pickers in the future, and releasing them as version updates to the same packages, we needed to consider whether it made sense to release the pickers as types on the existing Paste Input component. The reasoning behind that option was to avoid releasing a breaking change. If a consumer decided to use the date picker (as part of the Input package), we would still have the option of releasing a custom Date Picker down the line without that functionality, and without forcing the consumer to change their code.

Decisions!

The second API Exploration CodeSandbox provides further context on the two options, as well as the cross-browser testing findings. We wanted to take a deeper dive into the DOM methods' functionality because in the future, when we build the components from scratch, we'll have to replicate the functionality in order to avoid releasing a breaking change. The DSYS team decided to move forward with releasing the Stage 1 packages, and we'll convey (in the docs) that we won't be supporting the three methods in future updates. Consumers will have the option of using them, but they’ll be encouraged not to. This decision avoids confusion around having two separate packages for the same component, and there will be more standardization of Date and Time Pickers going forward.

---

Keep an eye out for our next release! As always, reach out to the DSYS team with any questions on Github Discussions or Slack.