-
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
lens should register expression functions in setup contract #110639
Conversation
@@ -21,7 +21,7 @@ import { UiActionsStart } from '../../../../../src/plugins/ui_actions/public'; | |||
import { Start as InspectorStart } from '../../../../../src/plugins/inspector/public'; | |||
import { Document } from '../persistence/saved_object_store'; | |||
import { LensAttributeService } from '../lens_attribute_service'; | |||
import { DOC_TYPE } from '../../common'; | |||
import { DOC_TYPE } from '../../common/constants'; |
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.
why this change?
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.
The main problem with export *
is, It cause excessive exports in required bundle see #110891. On the other hand if we are talking about build package it's important to don't load extra modules. Yes, I agree that it probably doesn't look professional, but it allow us optimize bundle size a little bit.
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'm fine with having specific export
directives, but in this case I'm unsure about the real gain here.
Do we have any measurable difference between import { DOC_TYPE } from '../common'
and import {DOC_TYPE} from '../common/constants'
? The item is exported via common/index
which is pretty much imported fully imported in the setup phase of Lens.
Isn't treeshaking already taking care of all these esm exporting implementation details?
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.
maybe if we avoid of using export *
it starts to work correctly, but I found extra code in final bundle from which we used only constants. Replacing to '../common/constants' solved that issue
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.
During the sync today Alexey demonstrated that changing this import gives us 4 KB of a smaller bundle. We agreed the change is worth it :)
# Conflicts: # x-pack/plugins/lens/public/lens_attribute_service.ts # x-pack/plugins/lens/public/plugin.ts
@elasticmachine merge upstream |
Pinging @elastic/kibana-vis-editors (Team:VisEditors) |
Co-authored-by: Marta Bondyra <[email protected]>
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.
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.
Code review LGTM
💚 Build SucceededMetrics [docs]Module Count
Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: cc @alexwizp |
heatmapGridConfig, | ||
axisExtentConfig, | ||
labelsOrientationConfig, | ||
getDatatable(formatFactory), |
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.
all functions should be registered on the server side as well (not necessary part of this PR)
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.
code LGTM
…110639) * lens should register expression functions in setup contract Closes: elastic#106510 * fix CI * build optimization * build optimizations - step 3 * fix CI * try to optimize bundle * Update x-pack/plugins/lens/common/expressions/time_scale/types.ts Co-authored-by: Marta Bondyra <[email protected]> * Update types.ts Co-authored-by: Kibana Machine <[email protected]> Co-authored-by: Marta Bondyra <[email protected]>
…#111324) * lens should register expression functions in setup contract Closes: #106510 * fix CI * build optimization * build optimizations - step 3 * fix CI * try to optimize bundle * Update x-pack/plugins/lens/common/expressions/time_scale/types.ts Co-authored-by: Marta Bondyra <[email protected]> * Update types.ts Co-authored-by: Kibana Machine <[email protected]> Co-authored-by: Marta Bondyra <[email protected]> Co-authored-by: Kibana Machine <[email protected]> Co-authored-by: Marta Bondyra <[email protected]>
Closes: #106510
Summary
lens expression functions are currently registered too late. they should be registered in setup life cycle to enable #106509
as functions are registered too late this will prevent us to run migrations on them, do reference extraction/injection or in the future use alerting or reporting services.