[EuiModal] Source order adjusted to annouce modal title before close

[Cedgo1997]

Summary

This PR introduces a workaround to solve the issue #7222, the following updates to the EuiModal and EuiModalHeader components, in addition to adjustments in the tests and styles moved based on the changed components.

1. EuiModal Enhancements:

   • Added a mechanism to pass onClose down to children that accept it.
   • Refactored children processing to enhance each child with the onClose prop if applicable.

2. EuiModalHeader Enhancements:

   • Added a onClose prop to support closing the modal directly from the header.
   • Introduced a close button (EuiButtonIcon) with proper accessibility (aria-label), now this close button is under the title, so it'll be annouce after.

Changes in modal.tsx

• Type Addition: Introduced ChildWithOnClose type to ensure children accepting onClose are type-safe.
• Enhanced Children: Utilized React.Children.map and React.cloneElement to inject onClose prop into child components.
• Removed Close Icon: Responsibility for the close button is shifted to EuiModalHeader.

Changes in modal_header.tsx

• Close Button: Added a close button using EuiButtonIcon with styles and localization via EuiI18n.
• onClose Prop: Introduced onClose prop to facilitate parent-driven close behavior.

Detailed Changes

modal.tsx

const enhancedChildren = React.Children.map(children, (child) => {
  if (React.isValidElement(child)) {
    return React.cloneElement(child as ChildWithOnClose, { onClose });
  }
  return child;
});

• This ensures that any child capable of handling onClose will receive it automatically, making the component more flexible.

modal_header.tsx

<EuiI18n
  token="euiModalHeader.closeModal"
  default="Closes this modal window"
>
  {(closeModal: string) => (
    <EuiButtonIcon
      iconType="cross"
      css={cssCloseIconStyles}
      className="euiModal__closeIcon"
      color="text"
      onClick={onClose}
      aria-label={closeModal}
    />
  )}
</EuiI18n>

• modal.tsx and modal_header.tsx styles were affected only to match reallocated code.

QA

Remove or strikethrough items that do not apply to your PR.

General checklist

• Browser QA
  • Checked in both light and dark modes
  • Checked in mobile
  • Checked in Chrome, Safari, Edge, and Firefox
  • Checked for accessibility including keyboard-only and screenreader modes
• Docs site QA
  • Added documentation
  • Props have proper autodocs (using @default if default values are missing) and playground toggles
  • Checked Code Sandbox works for any docs examples
• Code quality checklist
  • Added or updated jest and cypress tests
  • Updated visual regression tests
• Release checklist
  • A changelog entry exists and is marked appropriately.
  • If applicable, added the breaking change issue label (and filled out the breaking change checklist)
• Designer checklist
  • If applicable, file an issue to update EUI's Figma library with any corresponding UI changes. (This is an internal repo, if you are external to Elastic, ask a maintainer to submit this request)

[github-actions]

👋 Since this is a community submitted pull request, a Buildkite build has not been started automatically. Would an Elastic organization member please verify the contents of this pull request and kick off a build manually?

[JasonStoltz]

@Cedgo1997 Thank you for the contributions. We're looking for some time to review these, we'll be back to you shortly with feedback.

[acstll]

@Cedgo1997 thanks a lot again, for opening this!

I tried a similar approach with #8202 (I must admit less sophisticated 🙂), and the team raised some valid concerns, so I closed it. You can read the original comment here.

In summary, the implementation in this PR:

• doesn't handle recursively checking children (if a consumer wrapped EuiHeader); but also if for whatever reason EuiHeader is not included, we'll have no close button…
• it may introduce potential performance issues (I'm not so sure about this personally), but more importantly the Children.map is considered a legacy API, and I know it's used in other parts of the codebase, but we'd rather not introduce new usages

I'll double-check with the team and close this PR as we might just close the original issue as unplanned.

We highly appreciate that you took the time to make this contribution, and also the quality of it, which I find really good. So please don't feel discouraged.

[Cedgo1997]

@acstll Thank you very much for taking the time to review my PR. This was really helpfull. My best regards!