eui

eui copied to clipboard

#3476 and #3850 highlight different cases where features implemented in the vendored react-datepicker either cause problems (StrictMode warnings, from a third-party lib) or don't match the expectations of EUI consumers (popover service logic differences).

In both instances EUI provides components (EuiFocusTrap, EuiPopover) that would solve the underlying issue while providing a better overall feature experience. The current vendor structure disallows EUI components in ReactDatepicker, and changing dependencies in the vendor fork would cause even further divergence.

It's been discussed that EuiDatePicker could become a component composed of EuiFieldText, EuiPopover, and Calender (from react-datepicker). This would dramatically reduce EUI reliance on react-datepicker but would require a large amount of logic and functionality transfer (e.g., all open/close and moment parsing logic).

Want to open discussion on options to resolve open issues and decided on the future path of packages/react-datepicker/

//cc @chandlerprall

Action items:

• [x] move into src and merge dependencies
• [ ] move more logic and functionality into EUI
• [ ] pare down unneeded vendor components and dependencies

The right solution is probably bringing the vendored react-datepicker into src, moving its dependencies to eui's package.json, and adding the custom exceptions for jest, eslint, etc for its source code. We're only going to customize it more in the future.

A probably less effort, but future-compatible, effort would be to force react-datepicker's build to correctly map EUI components, allowing imports/usage. I think it would be straight forward for it to build with EUI, the really weird part is what happens when EUI builds: do we end up with 2 versions of EUI components or is there some magic wand to wave it away. The docs' webpack setup should be minimal but the production build seems iffy.

I'm all for reducing the amount of "skinning" we do of external libraries!

the production build seems iffy

Agreed.

I'll do some more exploration, but it seems that all we "need" from react-datepicker is the Calendar component. The popover service can easily be replaced with EUI's, and all the input heavy-lifting is done by moment. The order of operations could vary, but

• move into src and merge dependencies
• move more logic and functionality into EUI
• pare down unneeded vendor components and dependencies

All of the above sounds good to me. If we want to move the wrapping pieces like popovers into EuiDatePicker and remove them from react-datepicker, that is definitely the cleanest way for now 👍

👋 Hey there. This issue hasn't had any activity for 180 days. We'll automatically close it if that trend continues for another week. If you feel this issue is still valid and needs attention please let us know with a comment.

👋 Hi there - this issue hasn't had any activity in 6 months. If the EUI team has not explicitly expressed that this is something on our roadmap, it's unlikely that we'll pick this issue up. We would sincerely appreciate a PR/community contribution if this is something that matters to you! If not, and there is no further activity on this issue for another 6 months (i.e. it's stale for over a year), the issue will be auto-closed.

❌ Per our previous message, this issue is auto-closing after having been open and inactive for a year. If you strongly feel this is still a high-priority issue, or are interested in contributing, please leave a comment or open a new issue linking to this one for context.

Re-opening for consideration

Re-closing. Our long-term plans around EuiDatePicker and EuiSuperDatePicker will likely need a new meta issue. A quick note about long-terms plans:

• Get rid of react-datepicker dependency, use EUI internals only
• Plan for a single datepicker component instead of separate EuiDatePicker & EuiSuperDatePicker (new component entirely being worked in by Marcialis)