[EuiDatePickerRange] Respect endDateControl className prop

[thompsongl]

Summary

Use the className prop from the correct element (endDateControl)

Checklist

• Check against all themes for compatibility in both light and dark modes
  - [ ] Checked in mobile
  - [ ] Checked in Chrome, Safari, Edge, and Firefox
  - [ ] Props have proper autodocs and playground toggles
  - [ ] Added documentation
  - [ ] Checked Code Sandbox works for any docs examples

• Added or updated jest and cypress tests

• Checked for breaking changes and labeled appropriately

• Checked for accessibility including keyboard-only and screenreader modes

• A changelog entry exists and is marked appropriately

[cee-chen]

Perfection!! Great spot with the className fix as well!

[cee-chen]

@thompsongl Actually, sorry, 1 quick thought - do we want to add a small unit test for this? e.g.,

  it('uses individual EuiDatePicker props', () => {
    const component = render(
      <EuiDatePickerRange
        startDateControl={
          <EuiDatePicker popoverPlacement="left" className="hello" />
        }
        endDateControl={
          <EuiDatePicker popoverPlacement="left" className="world" />
        }
        {...requiredProps}
      />
    );

    expect(component).toMatchSnapshot();
  });

[thompsongl]

Can't argue with adding a test that's copy-paste-able

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_5329/

[cchaos]

The end date popover isn't aligning the same way as before anymore.
Before

After

Please, please, review the rendered components before auto-merging

[thompsongl]

Gah I did check the output locally, but apparently still had my override in place
Not quite sure how to handle this with how the default value comes through

[cchaos]

Yeah sorry, I think I meant specifically we need to check the published CI build. There could be other local issues that don't show up until you view the that version.

[cchaos]

Not quite sure how to handle this with how the default value comes through

I'm not sure we'd also want them to change the left/right position either. We may need to make this a custom prop asking for top/bottom position that affect both the start and end controls in one prop.

[thompsongl]

I'm not sure we'd also want them to change the left/right position either

It looks like changing left/right is what they want, not top/bottom: elastic/kibana#116471

Maybe there's a way to expand the isCustom prop to handle this. Like, have isCustom accept a configuration object that sets whether the 5-6 individual props are set during cloning:

<EuiDatePickerRange isCustom={{popoverPlacement: true}} /> // maybe `false` makes more sense?

Resulting in popoverPlacement not being added to the cloned element on L96. Behavior of isCustom without an object provided would remain unchanged

[cchaos]

I've asked for clarification: elastic/kibana#116471 (comment)

[cchaos]

Ugh, btw, none of this would be a problem if the popover was just one of ours inside of a portal.

[thompsongl]

Ugh, btw, none of this would be a problem if the popover was just one of ours inside of a portal.

Ughhhh you're right

[cchaos]

Found her a workaround. I think the ideal solution is to get ours rendering in a popover. We can do that by splitting the input from the calendar and putting in inline version in a popover. We do something similar in EuiSuperDatePicker. I started to explore the option in this codesandbox.

[thompsongl]

Thanks, @cchaos! I had the idea to use isCustom, but didn't put any code to it.
Really, it's probably time to start on #3901
The first step can be to move react-datepicker into src and swap out popper for EuiPopover, but I'll look at the level of effort required.

I'm going to scale this PR back to just the className fix and we can open a new PR with either your idea or a broader component reorg.

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_5329/

[cee-chen]

LGTM!

[cchaos]

👍 Maybe update the PR description too?