-
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
Expression forks #57491
Expression forks #57491
Conversation
Pinging @elastic/kibana-app-arch (Team:AppArch) |
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
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 looks good to me as well.
Trying to think through all of the possible scenarios that could come up. Should we ever allow adding to the main instance, or should that be reserved strictly for expressions plugin itself? Thinking of the scenario where Canvas is using a fork, but another plugin is just adding it's stuff directly to main.
@crob611 the idea here is that, both, Lens and Canvas would use forks. There would be default functions in the global registry provided by That was how I thought about it. But if you have further concerns, say Canvas does not want to make any expression functions available in their autocomplete besides the default ones and the ones explicitly registered by Canvas, we could do that too. We could add some method that returns an instance of |
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
Summary
Closes #56747
Checklist
Delete any items that are not applicable to this PR.
For maintainers