[APM] Typed client-side routing

[dgieselaar]

Closes #51963.

Whatever you do, don't look at the type definitions.

This PR adds typed client-side routing, by inferring route/path names and their expected path and query parameters.

Here's a demo:

Screen.Recording.2021-07-08.at.20.23.11.mov

I've profiled some tab switches in the service overview as well. Looks like a lot less stuff happens after this change. Here's the before, where you can see the main thread block for about 600-800ms on every tab switch:

Here's after, where there's almost no thread blocking:

I assume this is because there's less mounting/unmounting happening.

It works as follows:

Defining routes

Routes are defined according to the proposal for object-based routing in react-router@6:

import { createRouter, Outlet, unconst } from '@kbn/typed-react-router-config';

const routes = unconst([
	{
		path: '/',
		element: <Outlet/>,
		children: [
			{
				path: '/services',
				element: <ServiceOverview/>,
				params: t.type({
					query: t.type({
						rangeFrom: t.string,
						rangeTo: t.string
					})
				})
			},
			{
				path: '/services/:serviceName',
				element: <Outlet/>,
				params: t.type({
					path: t.type({
						serviceName: t.string,
					}),
					query: t.type({
						rangeFrom: t.string
					})
				}),
				children: [
					{
						path: '/overview',
						element: <ServiceOverview/>
					},
					{
						path: '/transactions',
						element: <TransactionOverview/>
					}
				]
			}
		]
	}	
] as const);

const and unconst() are necessary to have exact types, without the overhead of having readonly arrays and objects.

Outlet is a component that will render the element of an active route's child element.

Creating a router

The route definition should then be passed to createRouter:

const apmRouter = createRouter(routes);

The router has the following methods:

• link(routePath, params?): returns a link (a string) based on the routePath (which is the path defined in the route, concatenated with its parents). The type of params is based on the found route definition (and its parents), and is guarded by a runtime validation as well.
• matchRoutes(routePath?, location): returns matching routes up until the routePath, if it matches, or all routes if a wildcard is used. If only the location is given, it will return all matching routes.
• getParams(routePath?, location): similar to matchRoutes, but will validate, parse and return all parameters for the matched routes.

Rendering the routes

import { RouteRenderer, RouterProvider } from '@kbn/typed-react-router-config';
import { apmRouter } from './apm_route_config';

function App ( {}:{ history: History }) {
	
	return <RouterProvider router={apmRouter} history={history}>
		<MyCustomContextProvider>
			<RouteRenderer/>
		</MyCustomContextProvider>
	</RouterProvider>
}

RouterProvider renders a react-router context provider, to ensure its Route components still work, and its own context provider for the router passed to it.

RouteRenderer is the target for rendering the elements of active routes.

Hooks

• useRouter(): returns the router in context

• useParams(routePath): calls and returns router.getParams(routePath) for the router in context

• useMatchRoutes(routePath?, location): calls and returns router.matchRoutes(routePath?, location) for the router in context

• useApmParams(routePath): a typed version of useParams based on apmRouter

• useApmRouter(): a typed version of useRouter based on useParams

Examples

TBD

[elasticmachine]

Pinging @elastic/apm-ui (Team:apm)

[cauemarcondes]

@dgieselaar I see you defined the query params as required in one of the examples:

params: t.type({
  query: t.type({
    rangeFrom: t.string,
    rangeTo: t.string
  })
})

should we make it all optional since it comes from the URL and the user could manually remove it?

[dgieselaar]

should we make it all optional since it comes from the URL and the user could manually remove it?

They're required in the example, but optional in the application code. Preferably we make them required there as well, and figure out a way to set defaults on the route definition. If we make them optional everywhere, it's easy to forget passing them on. But let's address that in a follow-up PR.

[smith]

I truly love this.

I had some comments on the PR and a few things:

• Update the Routing and Linking internal docs
• When I'm on the service inventory and try to create any kind of alert there's an error about the routing
• The storybook for the latency chart needs to be updated to work with the new router. I can fix this in Jest and Storybook fixes #104991 so that's not a blocker

[smith]

TIL these exist. Some time soon I'll go and get us set up to use these automatically in Jest and Storybook.

[dgieselaar]

@smith updated the docs and fixed the issue with the alert flyouts.

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 94ab781
• Storybooks Preview

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
apm	1591	1559	-32

Async chunks

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

id	before	after	diff
apm	4.4MB	4.3MB	-115.0KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
apm	40.2KB	40.3KB	+71.0B

History

• 💚 Build #138436 succeeded 6c26486
• 💔 Build #138080 failed 51f6056
• 💚 Build #137515 succeeded b998fca
• 💛 Build #137479 was flaky eaf04c3
• 💔 Build #137443 failed 26373a7

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

[kibanamachine]

💔 Backport failed

Status	Branch	Result
❌	7.x	Commit could not be cherrypicked due to conflicts

To backport manually run:
node scripts/backport --pr 104274