[EuiProvider] Fix Security Solution code

[tsullivan]

Summary

Fixes needed for getting CI to pass when EUI throws an error if attempting to render a component without the EuiProvider in the render tree.

Detailed description

In #180819, I will deliver a change that will cause EUI components to throw an error if the EuiProvider context is missing. This PR comes in as part of the final work to get all functional tests passing in an environment where EUI will throw the error. The tied to the "Fix 'dark mode' inconsistencies in Kibana" Epic has so far been in preparation for this.

Reviewers: Please interact with critical paths through the UI components touched in this PR, ESPECIALLY in terms of testing dark mode and i18n.

Checklist

Delete any items that are not applicable to this PR.

• Unit or functional tests were updated or added to match the most common scenarios
• This renders correctly on smaller devices using a responsive layout. (You can test this in your browser)
• This was checked for cross-browser compatibility

[tsullivan]

/ci

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[patrykkopycinski]

Thank you @tsullivan

[nikitaindik]

Greetings @tsullivan! I have tested the changes and haven't found any issues. I changed the language and turned the dark mode on – both do get applied to the modal.

I've also noticed that "mountReactNode" has its own "I18nProvider", so the content ends up being wrapped twice.

I wonder if it would be possible to move KibanaRenderContextProvider inside mountReactNode. If we manage to do that, then we won't have to pass startServices here and will potentially cover more places at once. wdyt?

[tsullivan]

@nikitaindik great catch, and worthy of discussion. I would propose switching usage of { mountReactNode } from '@kbn/core-mount-utils-browser-internal' with { toMountPoint } from '@kbn/react-kibana-mount'. I'd prefer if mountReactNode was deprecated or only used in Core, if needed. We seem to have too many redundant utilities that do the same thing but slightly differently.

The file in question is security_solution/public/detection_engine/rule_details_ui/pages/rule_details/execution_log_table/execution_log_table.tsx. If we import toMountPoint there, we still have to pass startServices but it solves the issue of having 2 wrappers for i18n.

I put up a commit to do this, for your re-review: 97e75f8

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 08fdb8a

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
securitySolution	5490	5483	-7

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
securitySolution	15.1MB	15.1MB	-779.0B

History

• 💚 Build #211094 succeeded 8c81f31

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @tsullivan

[nikitaindik]

Thanks for adding the change @tsullivan! I have re-tested it locally and haven't found any issues. Can confirm that there are no duplication of I18nProvider.