load assets lazily in es-ui plugins

[mshustov]

Summary

Part of #62263
Implements lazy loading for management sections + share url.

name	size before	size after
share	837Kb	76 Kb
upgrade assistant	324Kb	59Kb
index management	3.2Mb	3.0 Mb
snapshot restore	3Mb	3Mb

[spalger]

LGTM

[cjcenizal]

Looks good, but can you help me understand the changes to Index Management and Snapshot Restore? Both of those apps were already lazy-loading before this change. So what do these changes accomplish?

[lizozom]

App arch change LGTM

[mshustov]

Looks good, but can you help me understand the changes to Index Management and Snapshot Restore? Both of those apps were already lazy-loading before this change. So what do these changes accomplish?

Index management uses singleton services that initialized on the first import. It means that:

• breadcrumbService
• documentationService
• httpService
• notificationService
• uiMetricService

present in the plugin bundle, even though they required when the app/management section is rendered.
I moved breadcrumbService & documentationService to be imported on management section mount lazily. I'm not familiar with your code good enough to move other services behind async loading and I leave it up to you.

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: b6a1617

History

• 💚 Build #38487 succeeded d0286a1

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

[sebelga]

Thanks for doing this @restrry !
So you recommend to move all the logic that we currently have in the plugin setup() cycle into the lazy-loaded "mount" file you've created?

// This is for example the logic for index_management

const { http, notifications } = coreSetup;
const { usageCollection, management } = plugins;

httpService.setup(http);
notificationService.setup(notifications);
this.uiMetricService.setup(usageCollection);

// And here we register the app with the `mount` handler
management.sections.getSection('elasticsearch')!.registerApp({ ...

Note: the gain on "snapshot_restore" is quite insignificant 😊

[mshustov]

So you recommend to move all the logic that we currently have in the plugin setup() cycle into the lazy-loaded "mount" file you've created?

To move everything that possible behind mount. It's usually related to UI-specific API. Note that you cannot use any setup API from in mount since mount is called after start.

[sebelga]

Are you saying that the above

const { http, notifications } = coreSetup;

is it not available in the closure?

setup(coreSetup: CoreSetup) {
  const { http, notifications } = coreSetup;

  management.sections.getSection('elasticsearch')!.registerApp({
    id: PLUGIN.id,
    title: 'myPlugin',
    order: 1,
    mount: async params => {
      // Initiate a service with core HTTP
	  // Is this possible?
      const apiService = new MyApiService(http);
      const { mountManagementSection } = await import('./mount_app');
      const services = {
        apiService,
      };
      return mountManagementSection(services);
    },
  });

[mshustov]

@sebelga Even if it works atm, you shouldn't rely on it in the future. setup is preparational phase. you shouldn't use any setup API (besides getStartServices) after your plugin started.

[sebelga]

Ok, thanks for clarifying @restrry !