Skip to content
This repository was archived by the owner on Jan 11, 2023. It is now read-only.

Conversation

@joecorkerton
Copy link

Potential solution for #85

Reason for diffs on other lines is due to elm format being automatically run. Can remove these changes if required.

@bbqbaron
Copy link
Collaborator

Simple enough! Looking at the code, it seems like Focus and MouseDown differ in whether they set forceOpen, which determines whether the picker will close when blurred. I don't have a strong opinion, but would you intuitively assume something called open would force the picker open, or just transitorily open it and allow it to close itself?

We can always expose both, of course!

@joecorkerton
Copy link
Author

joecorkerton commented Jul 12, 2018

If you open the picker via the method I created it will stay open until you select a date (because the blur event which would usually happen never gets triggered). For me forceOpen would mean that the datePicker wouldn't close when I select a date. Personally this is the not behaviour I am interested in and so have not exposed that, but it could be done in a similar way.

open is also consistent with the isOpen function, which is looking at the open attribute (and not forceOpen)

I have added another commit with a close method, which triggers this blur event (so that I can close the datepicker if the user loses focus of my other input) and tidied up the comments a bit

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants