Feeling out future direction of datetimepicker

[avh4]

Hi! We're using datetimepicker in our app, but are going to need some UI changes for user experience needs on our particular app. We're wondering if it will be best in the long-term to a) contribute back our needed changes, b) contribute back API changes that allow us to customize for our needs, c) fork and just start maintaining our own datepicker specific to our needs.

Here are some of the specific things we're planning to need:

• for datetimepicker, provide a default time when initializing, but no initial date (so that as soon as a date is selected, the datetime is valid (as opposed to having to click hour/minute/pm also))
• there are certain other dom events that can cause focus to leave the input without updating the datepicker state (mousedown, touchstart)
• more flexible date parsing (for strings that the user manually types in)
• we need to be able to handle specific non-date strings; for example, we want "right away" (case insensitive) to map to Just RightAway, and other dates to map to Just (SpecificDate Date), and other things to map to Nothing.
• limiting date selection to a particular range
  • disable dates in the past (see Option to prevent selection of dates in the past #26)
  • limit the year selector to (this year, next year)
• Customize the styles of the text input (including extra dom elements for overlaying an icon)
• have a way for the calling code to dismiss the popup
• cleaner handling of timezones (see Cleaner handling of timezones #27)
• better UX for mobile devices

Do all/most of the above seem like things that you'd be willing to take PRs for, or does it seem like our needs will diverge from what the future plans of datetimepicker are? Should I create separate issues to further discuss each/any of these?

Thanks!

[abadi199]

I think I want most the things you listed here, and the rest, I don' see any reason not to add to this package. I think the best solution is to try to implement b), if we can't do it through API changes, then we can talk about implementing a). Let's make separate GitHub issues for each of the items on the list.

The only problem is, I don't have enough free time that I can spend on working/reviewing PR on this package. If you want, I can make you or any other people from your team a push access to this repo. Let me know what you think.

Thanks.

[avh4]

I'd be happy to have push access (I'd probably be the best from our team).

But I'd be concerned about what things I should be comfortable merging without input from you:

• bug fixes (seems fine to merge)
• refactoring of existing code w/out behavior changes (maybe you want input on this depending on the significance of the change?)
• additions to API (maybe you want some input on this?)
• changes to existing API / major version bump (I assume you'd want input on this kind of change?)
• changes to UI (I assume you'd want control over this kind of change?)

(For things you would want to have input on, I could still plan to do most of the work and just get brief input from you if you have time for that.)

Where do you think the line should be?

[abadi199]

I think the 1st and 2nd point, you can just go ahead and merge those changes.
If it's an additions/changes to API, I will try to make times to discuss those changes before we implement those, and the same thing with UI changes.

[avh4]

Okay, sounds good!

[avh4]

I plan to make PRs for new things anyway, but for bug fixes and refactoring I'll just merge after a day or two. (FYI, I'll also have a PR soon setting up Travis-CI.)