Implement a generic solution to execution context propagation inside Kibana

[xcrzx]

Summary

In #131805 we introduced a wrapper around the Route component from react-router-dom (see src/plugins/kibana_react/public/router/router.tsx). This wrapper is intended to be used in Kibana across all solutions for automatic propagation of execution context when a user changes route. To do that:

1. We need to extract the route wrapper from the @kbn/kibana-react-plugin package to a separate single-purpose package, something like @kbn/shared-ux-router. This is yet to be discussed with @majagrubic and @clintandrewhall
2. To make the transition easier, we want to re-export other react-router-dom exports alongside the modified' Route'.
3. Solutions should start using that Route component in place of the one from react-router-dom. I.e. replace all occurrences of import { ... } from 'react-router-dom' with import { ... } from '@kbn/shared-ux-router'.
4. All manual calls to useExecutionContext are not needed anymore and should be removed.
5. After the transition is completed, we can introduce an ESlint rule that ensures that react-router-dom is not used directly in Kibana and that imports go through the new @kbn/shared-ux-router package.

For more context see this discussion: #131805 (comment)

[elasticmachine]

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

[lizozom]

@xcrzx wanted to check in about the status of this :-)

[lizozom]

As per @xcrzx working on this issue was postponed.
Moving back to backlog.

[lukeelmers]

@rshen91 @xcrzx @lizozom Was this issue addressed in #138544, or is there more to do here?

(Edit: I guess we need each of the remaining apps to switch to using the shared router then?)

[xcrzx]

I guess we need each of the remaining apps to switch to using the shared router then?

Yes, that's correct. Once all apps are migrated to the shared router, we can close this issue.

[lukeelmers]

Do we have anywhere we are tracking which apps still need to migrate? I'm happy to help chase people down if it helps push things forward :)

[xcrzx]

Do we have anywhere we are tracking which apps still need to migrate? I'm happy to help chase people down if it helps push things forward :)

I don't know of any ticket besides this where the progress is tracked. I believe only the security solution has migrated to the Route component with automatic execution context propagation. So all other apps are yet to follow.

Probably the easiest way to see what plugins need to be migrated is by making this ESLint rule global (currently, it is enabled only for security solution plugins) and collecting all errors:

kibana/.eslintrc.js

Lines 1007 to 1014 in 4de1ab5

	paths: [
	{
	name: 'react-router-dom',
	importNames: ['Route'],
	message: "import { Route } from '@kbn/kibana-react-plugin/public'",
	},
	],
	},

The migration itself should be pretty straightforward. Plugins need to replace Router imports from react-router-dom with imports from @kbn/kibana-react-plugin and remove manual calls to useExecutionContext if there are any.

@lukeelmers Please let me know how I could help move this effort forward.

[clintandrewhall]

We could start by adding this eslint rule to a PR and see what blows up?

[xcrzx]

We could start by adding this eslint rule to a PR and see what blows up?

Created a draft PR: #145863.

[lukeelmers]

Plugins need to replace Router imports from react-router-dom with imports from @kbn/kibana-react-plugin and remove manual calls to useExecutionContext if there are any

I'm seeing ~15 plugins that are calling useExecutionContext, and all of the rest of the changes would be simply updating import statements. If this is all that needs to happen, I wonder if it would be worth prioritizing this on the Kibana side instead so we can call it done. Getting the individual codeowners of these plugins to make changes on their end could take months. WDYT @clintandrewhall?

The reason I'm interested is because we have some large-scale users who have been asking for Kibana-wide execution context propagation, and this is the last thing preventing us from being able to say that it is officially supported everywhere.

[lukeelmers]

@elastic/kibana-global-experience Just wanted to bump this for y'all to consider when prioritizing upcoming work. Seems like it could be a relatively easy win and a big benefit for some of our largest deployments.

[rudolf]

@vadimkibana My understanding is that the scope of this work is relatively small. But there is enormous value in having richer execution context across the whole UI. This would allow both us and users to better attribute where load on Kibana/Elasticsearch is originating from which is a highly requested feature.

Is there a reason this work has been cancelled?

[lukeelmers]

I was under the impression that #150357 addressed the full scope of this issue, but I may be mistaken.

[xcrzx]

This ticket was fully addressed in #150357, so closing it as completed