@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();
  });

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

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

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

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.

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.

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

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

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

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

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.

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.

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