It’s an open secret among devs, almost a joke, that Javascript datepickers suck, hard. But why? As I’ve implemented story scheduling here at Hacker Noon, so we can schedule a story to be published at a specific date/time, I’ve come to understand why they suck so badly (at one point, even trying to write my own).
Some datepickers suck worse than others, as I quickly discovered early on in the dev process. Hell, half of the work involved here was picking the right datepicker. First of all, I should mention we’re using React on app.hackernoon.com, so that limits our options right off the bat. See, some datepickers have an
onChangevalueSetting the state of a datepicker isn’t that bad, whether it’s handled for you or you handle it yourself. The capital-H Hard Part™️ is configuration. Should the user be able to pick a time in the past? Should they be able to pick a date one year in the future? Should they be able to pick any time, or should it go in 5 minute increments? 15 minutes? Do the date picker and time picker have controls? Can these controls be modified? What about the date and time displays?
The displays in particular were a pain in the ass. The thing is, we had to customize the displays such that we could see the number of stories scheduled for each day, and ideally, each time slot as well (in 15 minute increments). It wouldn’t do just to click on the day/time and see the number -- you want to be able to see the big picture at a glance and select a day based on where stories are needed. The first method described would be too cumbersome.
So what does this have to do with the price of butter?
Many of the libraries I looked at offered either time interval configuration, or interface customization, but not both. They offered date validators, but not time validators. They would offer some subset of the features we needed, but it seemed that nothing quite fit our use case.
So I decided, with some nudging from Dane, to write my own date/time picker. In retrospect, this was probably not the best route, but we figured that in keeping the interface and rules simple, we could vastly simplify the datepicker for our use case.
It turned out that there were a ton of edge cases related to time (surprise, not surprised). I mean, I fixed all of the edge cases that came up, but I was certain there would be cases I missed (like odd time zone changes/consolidations/splits in other countries, for example). At Storm’s suggestion, I ended up trying react-datepicker, one library I had tried before, but found the time restraint config lacking. The solution ended up being to check for times in the past, and prompt the editor to either publish immediately or choose another time -- it’s worked well so far.
The only hitch with react-datepicker is that you can’t really customize the date or time displays beyond adding classes. This ultimately means that we can color-code the divs, but we can’t add a number or anything like that unless we use some sort of
::before::afterSo how does it look for Hacker Noon editors? I added a Hacker Noon clock icon button near the end of the editor flyout menu:
And then once the clock is selected, the editor chooses a time (pro-tip: noon is a good time to publish).
And then it publishes at the scheduled time, going off into our story distribution machine:
Speaking of iterating at Hacker Noon: we will be improving workflows, leveling up communication around publication times, making a better editor view to scale our publishing themes , and eventually getting the story scheduler in the hands of our writers.
In the end, no library is ever perfect, but it seems date/time pickers are a special case where all the behavior you need is there except one key feature, or split between two tools, or what have you. I’m glad we found a solution that works for us (and I’m glad I was able to make the editors’ lives easier), but I would like to tackle the datepicker problem at some point. I have just enough hubris left from my early 20s to think: maybe I could do it right? Eh, we’ll see. For now, back to the internet!