Lazy loading React components

[mshustov]

I created this issue to discuss the lazy loading strategy for react components used by different registries in Kibana. If you build Kibana platform plugins locally and check their sizes. You can notice that maps plugin size reaches 4.8Mb. That's mostly due to new optimizer architecture including all the plugin dependencies in the bundle and lack of code tree-shaking (WIP https://github.com/elastic/kibana/pull/62390). Even if we move some deps to shared dependencies and remove unused code, the build size will be quite significant (@elastic/ems-client, @elastic/maki only gives us 1Mb) Ideally, a plugin code should be as slim as possible and include the thing that necessary for proper registration. All other code must be loaded on demand.

I'm wondering if we can improve the situation with loading Maps React components on demand. To understand how it affects the initial load time let's look at maps.plugin.js size (this is the chunk loaded every time a user opens the Kibana): without lazy loading - 4.8Mb with MapViewComponent loaded lazily - 29Kb

There are several approaches to address the problem:

• we can add lazy loading for React components (https://github.com/jamiebuilds/react-loadable, for example)
• we can make registry compatible with async integration points (as management app and expression render do)

Maybe @elastic/kibana-app-arch has other ideas or opinion of whatever pattern is preferable?

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[elasticmachine]

Pinging @elastic/kibana-gis (Team:Geo)

[mshustov]

We have the same problem for visualizations registry as well:

• vis_type_timeseries plugin - 4Mb
• vis_type_markdown plugin - 2.8Mb
• vis_type_metric plugin - 2.4Mb

[elasticmachine]

Pinging @elastic/kibana-operations (Team:Operations)

[Dosant]

Wonder if React.lazy and Suspense are working in Kibana env? If yes, I guess we won't need react-loadable?

[mshustov]

@Dosant yes. I did try it in our app and all integration tests passed. https://github.com/elastic/kibana/pull/64285 Regarding the other infrastructure:

• Enzyme added Suspense support in 3.10.0 https://github.com/enzymejs/enzyme/issues/1917 We have 3.11.0 version in the repo. https://github.com/elastic/kibana/blob/90f5ce0ef34885373d43bd613ac382a5ab9aee15/package.json#L409
• @testing-library/react doesn't use any magic and implements DOM polling. There is an example: https://github.com/kentcdodds/react-testing-library-examples/blob/d421e52dac6870c1f56cc34f5a35ce9f42ab6ef8/src/__tests__/react-lazy-and-suspense.js for v9 version that we use https://github.com/elastic/kibana/blob/90f5ce0ef34885373d43bd613ac382a5ab9aee15/package.json#L309

I think you can use React.Lazy if you want. Do you want me to create a separate issue for @elastic/kibana-app-arch team to refactor visualizations plugins? That would be great if we can have it fixed until FF v7.8. There are some complaints about Kibana loading time.

[Dosant]

@restrry, thanks for checking react.lazy 👍 I guess which team fixes it depends on where we do lazy loading. If lazy loading will be handled inside each visualisation type by it's own - then I guess it would be @elastic/kibana-app. But if we somehow make it part of visualisations infrastructure, then @elastic/kibana-app-arch. I'll bring in up to the team

[timroes]

Related to https://github.com/elastic/kibana/issues/58280

[Dosant]

@restrry, @elastic/kibana-app-arch is going to look into generic approach for code splitting of app arch registries and components during our next planning week. In a meantime, if possible during 7.8, we suggest @elastic/kibana-app to look into specific visualisations implementations and wrap them with React.Lazy where it would benefit the most.