-
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
[data views] Move data views api from data plugin and into its own #113497
Conversation
@elasticmachine merge upstream |
@elasticmachine merge upstream |
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.
VisEditors changes LGTM 🆗
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.
ML changes LGTM
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 🚀
Noticed couple issues that could be addressed:
preset: '@kbn/test', | ||
rootDir: '../../..', | ||
roots: ['<rootDir>/src/plugins/data_views'], | ||
testRunner: 'jasmine2', |
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.
could try to remove 'jasmine2'
override here. maybe it would all pass with default runner
"server/**/*.json" | ||
], | ||
"references": [ | ||
{ "path": "../../core/tsconfig.json" }, |
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.
Likely not all of these references needed for data_views plugin
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.
Changes under operations team code owners LGTM
… into data_views_to_own_plugin
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.
I think the intention here is good, but I don't think splitting views out of the data plugins is actually helping. Splitting plugins is not a good way to separate concerns and the overall impact on initial page load bundles is +11kb. I think we should take another approach here.
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.
I've misread the bundles info here. If the goal here was to reduce the overall bundles size, it actually did the opposite. Thanks @spalger for double checking this
I'm confused by this in part because this PR is pretty clean meaning there was a relatively good separation of concerns to begin with. Having two plugins instead of one should encourage maintaining this separation. Is there an alternative approach you recommend?
We have a goal to keep bundle sizes below 100kb but I'm unaware of any guidelines around limiting total payload growth, particularly around something as small as 11kb. I haven't investigated it yet, but I suspect the additional 11kb is because the data plugin reexports most of the data views plugin exports. This is to limit the overall impact on the code base due to splitting plugins. That said, I suspect you have more experience thinking about these things - what overhead can we expect introducing a new plugin? How many kb? |
No, the goal was to reduce the size of the data plugin, which it did. The goal was not to reduce overall bundle size - I would expect some amount of combined bundle size increase by separating plugins. This is 2% growth compared to the starting point. Its not desired but I don't understand why it would dissuade from moving forward with this. Here's where we split out field formatters from the data plugin - #107173 - Page load bundle sizes grew by 14kb and more specifically a 11.7kb growth from data plugin including field formatters vs field formatters in its own plugin. |
💚 Build Succeeded
Metrics [docs]Module Count
Public APIs missing comments
Any counts in public APIs
Public APIs missing exports
Page load bundle
Unknown metric groupsAPI count
References to deprecated APIs
History
To update your PR or re-run it, just comment with: |
@mattkime and I have discussed this at length and agree that this doesn't meet the goal of improving page load time or reducing bundle sizes, but think that it ultimately is worth merging for the purpose of encapsulating the "data views" and eventually being able to move that into a package. I've agreed to work with the app services team and help consult on further efforts to reduce the size of the data plugin, which we really should be able to do. We will prevent many data* plugins from being created and I think we can accept this 11.5kb debt for now. |
💔 Backport failed
To backport manually run: |
…lastic#113497) * initial pass at moving data views into own plugin * require expressions plugin, fix META_FIELDS reference * bundle limits and localization * fix integration test * update plugin list and jest config * type fixes * search fixes * fix localization * fix mocks * fix mocks * fix stub * type fixes * fix import on test file * path fixes * remove shorted dotted from data plugin * more todo removal * eslint fixes * eslint fix * simplify data views server plugin * simplify data views server plugin * simplify data views server plugin * fix imports on api routes * fix imports on api routes * update plugin list * ts fixes * ts fixes * add deprecation notice * fix circular dependency and api integration test * fix circular dependency and api integration test * rename types for better clarity * path fixes * jest.config and tsconfig cleanup Co-authored-by: Kibana Machine <[email protected]>
…own (#113497) (#113833) * [data views] Move data views api from data plugin and into its own (#113497) * initial pass at moving data views into own plugin * require expressions plugin, fix META_FIELDS reference * bundle limits and localization * fix integration test * update plugin list and jest config * type fixes * search fixes * fix localization * fix mocks * fix mocks * fix stub * type fixes * fix import on test file * path fixes * remove shorted dotted from data plugin * more todo removal * eslint fixes * eslint fix * simplify data views server plugin * simplify data views server plugin * simplify data views server plugin * fix imports on api routes * fix imports on api routes * update plugin list * ts fixes * ts fixes * add deprecation notice * fix circular dependency and api integration test * fix circular dependency and api integration test * rename types for better clarity * path fixes * jest.config and tsconfig cleanup Co-authored-by: Kibana Machine <[email protected]> * localization fix Co-authored-by: Kibana Machine <[email protected]>
Summary
Moving the data views api from the data plugin into its own plugin to shrink the data plugin bundle size and for better separation of concerns.
In order to minimize the impact of this change, the data plugin provides the data views api and re-exports data view exports. This should be removed once all api consumers are using the data view plugin directly.