How to/is it possible to have date picker with manual input disabled?

[bobwhitelock]

I searched and looked through the API and couldn't see how to do this, but apologies if this is explained somewhere.

Basically in my use case only a few dates are selectable, roughly 1 in 10 over a ~20 year time period, so I'm using the isDisabled setting to disable the others. Therefore I thought it would make things more usable to disable manually changing the date picker input and just have users select the date through the date picker itself. Without doing this most dates that could be manually entered would be invalid, meaning the data displayed based on the selected date will not change, which is not very nice UX.

The ways I could imagine this working is either the date picker input remains selectable, to bring up the date picker, but is un-editable, or the input is disabled but an alternative message can be dispatched to show/hide the date picker. Is either of these possible with the current API? And if not, can anyone suggest possible changes to it to support this? (I'm happy to have a look at adding this to the package if it's not currently possible, but would need some guidance as to how the API should look and how to go about this.)

Thanks :slightly_smiling_face:

[bbqbaron]

Thanks for the thoroughness of your issue! I don't think this is currently possible. Your use case makes perfect sense, though. The API can probably accommodate a few different scenarios, and I'm happy to answer questions on how it should be implemented.

It seems fairly straightforward to add the ability to enable/disable the manual input. I think the only issues to think about would be:

• this means a major version bump (an unfortunate side effect of Elm's lack of optional object keys and enforced semver). Can't really be avoided, I don't think, without getting very exotic.
• do we want the input to be disabled or just not to render? Perhaps we could even take a type InputFlags = Disabled | Invisible, since they're both pretty easy and we may as well provide them.

[bobwhitelock]

Thanks for your speedy response, and apologies for the delay getting back to you.

Regarding the two points you mentioned:

this means a major version bump (an unfortunate side effect of Elm's lack of optional object keys and enforced semver). Can't really be avoided, I don't think, without getting very exotic.

This doesn't seem too bad to me, and Elm makes these sort of upgrades relatively painless compared to some other languages. However if I do implement this and it gets merged, and you want to leave it unreleased for a while so you can batch together other breaking changes in one release, then that's fine by me.

do we want the input to be disabled or just not to render? Perhaps we could even take a type InputFlags = Disabled | Invisible, since they're both pretty easy and we may as well provide them.

Regarding making the input disabled or invisible, I may be missing something but it looks like these could already be done with the existing API: using the inputAttributes setting, a disabled attribute could be added to the input, or a style attribute with display: none could be used to effectively make the input invisible. I tried the former of these in my app, however the issue with this was that there then was no way to get the input to show the date picker since the input could not be focused.

Given this then, as far as I can see it seems the most minimal change to support this API would be to add an open function, similar to the current pick function, which would produce a message to open and focus the date picker. This could then be dispatched e.g. using a button alongside the disabled/invisible date picker input.

Once the date picker was opened via this message, it could then be closed in the usual way by selecting a date or unfocusing it. However, for consistency it may make sense to also add a close function so the date picker could also be closed using this if desired (e.g. it might be nice to have the same button which shows the date picker also close it when clicked again).

Let me know what you think of this suggestion, or if I've missed anything here.

[bbqbaron]

Brilliant. I see your point about disabled; if the input is also the sole "open" button the user is kind of hosed. I think this all makes perfect sense. Just to clarify, the consuming code (ie not us) is expected to create the button that sends open? Ie we don't render such a thing in place of the input, but rather leave it to the rest of the app to determine how to activate the picker?

[bobwhitelock]

Yep I think that would be the most flexible API - the DatePicker.view function will still always render the date picker input, which can independently be set to be disabled, not visible etc. Then this suggested change would add open and closed functions to add an alternative means of opening and closing the date picker.

These different features could then be combined to support a wider variety of interfaces, e.g. having a button to open/close the date picker, or having the date picker automatically open when the page is scrolled to a certain point.