-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Convert global timepicker/datepicker to EUI/react #13525
Comments
Designs for K7, which is mostly a reskin, just in case you need them for your decisions. From designs standpoint we are moving completely off of bootstrap for K7, so our request is simply to use something that has independent theming / styling capabilities if possible. If not, we can always make some custom stuff to lay on top, but it might hurt maintenance. |
We zoomed today and decided to apply some minor fixes to address the worst accessibility issues in the current datepicker. Longer term we'll look at replacing it with something better. This issue is a pretty good summary, so I'm gonna hijack it for tracking that larger effort. An ideal datepicker would be:
The current date picker, a fork of an old angular bootstrap component, is none of the above. A better solution might be a vanilla JS library, a react component, or possibly something completely custom. |
@Bargs @timroes I am starting to take a look at replacing the current timepicker with a react version. Custom time ranges per panel will require all of the time picker components as used in the global timepicker. Most of dashboard is now react so we need react components so it seemed like a good time to update the timepicker |
|
Closed. New timepicker is now in Kibana |
We are currently having a lot of accessibility issues with the currently used datepicker, which is from Angular UI Bootstrap. The sources were pulled over which makes updating currently a miss. Also we would need to refactor large parts of the code that we pulled over to modify the custom keyboard controls (using arrow keys to navigate), to be accessible with that component.
Since we are currently building the UI framework with React components, this might be the perfect time to move to a React date picker, and if we need to fix accessibility issues, directly fix them in the new component (or upstream if we are using a library).
Since we would prefer using regular dependencies (for maintenance reasons) instead of pulling source code over, we "just" need to decide what a good dependency would be, and maybe create a wrapper component in Kibana for it. That way we would be free to change the underlying implementation at any time as long as the wrapper has a stable API.
I've previously used react-datepicker which is a pretty solid library, but unfortunately does neither provide any accessibility right now. I would prefer having a stable and solid library at the moment without a11y and providing this upstream instead of having a maybe less popular, less maintained library, that HAS a11y.
The text was updated successfully, but these errors were encountered: