-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Maps] Code split Maps app #64594
[Maps] Code split Maps app #64594
Conversation
Pinging @elastic/kibana-gis (Team:Geo) |
Yeah, the rule of thumb is the higher Lazy component will be in the react tree the better. |
Did not have much time today to try solutions, but I confirmed removing the I'm not sure when these need to be registered. Does this just need to be called before the embeddable renders and before the application mounts? If so, I think we can drop an async import in the embeddable rendering code. |
Before the embeddable renders is sufficient, so it doesn't need to be in |
…to maps/lazy_load
import { HomePublicPluginSetup } from '../../../../src/plugins/home/public'; | ||
import { VisualizationsSetup } from '../../../../src/plugins/visualizations/public'; | ||
import { MAP_SAVED_OBJECT_TYPE } from '../common/constants'; | ||
import { MapEmbeddableFactory } from './embeddable'; | ||
import { MapEmbeddableFactory } from './embeddable/map_embeddable_factory'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
don't pull from the index.ts
file as it brings in the actual Embeddable
. Just pull in the factory.
x-pack/plugins/maps/public/embeddable/map_embeddable_factory.ts
Outdated
Show resolved
Hide resolved
Pretty interesting stuff. Left some minor comments. Need to dig into this a bit more to understand some of the details.Thanks for taking this one on! 🤾♂️ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for shrinking the maps plugin initial install size.
Can you remove the lazy load for MBMapContainer
. Since this is used within GisMap
, lazy loading GisMap
will be sufficient.
Also can you remove gis_map/shim/index.ts
and just change gis_map/index.ts to return default export
From the Uptime side I ran this locally and our map shows up like normal 👍 Not going to LGTM because it looks like the review/work for the feature is ongoing still. |
As of 231fb6d this is looking good on the SIEM side, but I'll double-check once this branch settles. |
@elasticmachine merge upstream |
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
code review, tested in chrome and firefox
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Checked this out again just now: from SIEM's perspective, things look/function as expected! 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great! I don't see any more obvious opportunities to split anything else out of the main bundle (which is now only 46kb gzipped!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For Uptime, the map still LGTM 👍
Code-split the maps-plugin to reduce the initial `maps.plugin.js` size. There were two main code dependencies in the plugin initialization that were the root cause of the large bundle size. - `GisMap` wraps the entire application UX, including the add-layer-wizard. The layer wizards only need to be available there. This PR moves the `load_layer_wizard` dependency from the plugin-initialization to the `GisMap` component. - The `MapEmbeddableFactory` needs to be registered at plugin-initialization. However, this module imports a lot of core-application code. By code-splitting here, we avoid pulling in the entire Maps-app in the main bundle. This also introduces a lazy-initialization of the `GisMap` itself as an additional split to further reduce size of the bundles.
* [Maps] Code split Maps app (#64594) Code-split the maps-plugin to reduce the initial `maps.plugin.js` size. There were two main code dependencies in the plugin initialization that were the root cause of the large bundle size. - `GisMap` wraps the entire application UX, including the add-layer-wizard. The layer wizards only need to be available there. This PR moves the `load_layer_wizard` dependency from the plugin-initialization to the `GisMap` component. - The `MapEmbeddableFactory` needs to be registered at plugin-initialization. However, this module imports a lot of core-application code. By code-splitting here, we avoid pulling in the entire Maps-app in the main bundle. This also introduces a lazy-initialization of the `GisMap` itself as an additional split to further reduce size of the bundles. * fix merge Co-authored-by: Elastic Machine <[email protected]>
Closes #64317
Code-split the maps-plugin to reduce the initial
maps.plugin.js
size.There are two main code dependencies in the plugin-init that are the root cause of the large bundle size.
load_layer_wizard
dependency from the plugin-initialization to theGisMap
component.GisMap
wraps the entire application UX, including the add-layer-wizard. The layer wizards only need to be available there.MapEmbeddableFactory
needs to be registered at plugin-initialization. However, this module imports a lot of core-application code because of its redux-selector dependencies. By code-splitting here, we avoid pulling in the entire Maps-app in the main bundleThis reduces the maps.plugin size from 5+MB to around 300kb.
Not sure if we really need to preserve the
<Suspense>
loading of the React-components. I can leave it/remove.todo:
WIP - just a POC@restrry I'll need some guidance on where to exactly introduce this. You referred to theMapViewComponent
(
kibana/x-pack/plugins/maps/public/inspector/views/map_view.js
Line 12 in 5cab334
in #64317 (comment), but this is just the code for the inspector.I introduced it a little closer to the actual map, but that isn't really making any dent in the bundle size.