Why I'm Not Using Your Datepicker

Published on

Your poison of choice for building web UIs may vary, but one thing you can always depend on there being, is an ecosystem of feature-rich select boxes, popovers, modals, burger menus, and yes, date-pickers. I’ve been responsible for at least one of them.

Aside from the dark times when I had no idea what I was doing with the DOM and ended up using jQuery UI, along with some flirting with chosen, select2 and selectize, I’ve usually tended towards committing the cardinal sin of programming -- implementing them for myself from scratch.

In the past my reasoning has been about perfectionism, i’ve wanted to control the display of these components so that they look at home in a design, but now I’m convinced there are stronger arguments. It’s mainly down to the typical lifecycle of a component from in-house solution to widely-used open source solution. Someone following this lifecycle may go through the following steps:

What’s going wrong?

Why does this pattern tend to repeat in every JavaScript ecosystem (jQuery, React, Angular, Ember etc)?

Third-party components do let us get up and running quickly, but the frustration using them always appears sooner than you’d think. So what’s the solution? I have two ideas, I think both may help:

  1. Release the code to your solutions, but don’t make them trivially installable. You want to make your code easy to follow, but you don’t want to support anything other than your own use cases. Documented example solutions to problems are hugely useful, and the benefits will grow as more of them appear. When people come to need something similar for themselves, they’ll be able to find some examples and use one of them as a starting point for their own requirements.

  2. Solve more lower-level problems, this doesn’t mean going as far as the almost farcical node.js nano-packages, but there’s a good compromise to be found. Date-pickers, select boxes etc all tend to require accessible popovers. The problems of positioning popovers and making them accessible are independent of the functional challenges of writing a good date-picker. If i’m going to write my own date-picker, having these problems solved will save a lot of time.

To elaborate on the second point, in functional terms, a date-picker looks something like this (forgive the weird syntax I just invented):

Datepicker = Selected<Date> + compose(AccessibleLayer, LayerPositioning, Calendar<Date>)

A select box looks something like this:

SelectBox = Selected<Option> + compose(AccessibleLayer, LayerPositioning, List<Option>)

When you look at how these components are composed, it becomes easier to see which problems will provide the most benefit when solved in a re-usable way.

One important caveat to mention. It‘s possible that your Calendar or List requires some knowledge of how it’s being used, selecting a date or option might require that you close your popover as well, a change in your options list might require a recalculation of layer positioning. I don’t have ideal solutions for these yet, so I welcome any discussion about it. There’s a few patterns i’ve explored, but I’m still ironing out the details.

The JavaScript world is heading towards a heavily-component oriented future, but we shouldn’t repeat the mistakes of the jQuery-era -- we should be thinking about enabling easy composition rather than providing every feature out of the box. As a community we’re learning the benefits of the functional programming paradigm, it’s not easy to get right, but it’s going to be worth it in the end. The end result is going to be a better development experience, smaller download sizes, and more consistent accessible UIs for our users.