-
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
Migrate share registry #50137
Migrate share registry #50137
Conversation
💔 Build Failed |
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 starting on this -- I took a look at it today, and overall this makes sense to me. TBH I am not sure why we had listed kibana_react
as a destination for this functionality in our migration meta issue. Presumably because there was an idea that some of that static components could be shared from there? I prefer your approach of exposing the minimal possible API surface area as a start, especially as this is likely to evolve during migration still. (For example, there's the url shortening REST API src/legacy/server/url_shortening
, which still hasn't been migrated and we will eventually need a plan for).
The only thing I'm going back and forth on is whether share
is a wide enough domain to justify a standalone plugin. Since this functionality doesn't neatly fit as a service inside of one our existing plugins, I think this makes sense for the time being. I'll mull this over a little bit, and will also do some testing on this PR tomorrow.
💔 Build Failed |
💔 Build Failed |
💔 Build Failed |
💔 Build Failed |
💔 Build Failed |
💔 Build Failed |
Jenkins, test this |
Marking this ready for review because I'm 99% certain the build failures are just infrastructure/flaky test ones at this point. |
💚 Build Succeeded |
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.
Tested locally (Chrome OSX) and everything LGTM! Thanks for doing this.
One favor to ask - Would you mind also adding ui/share
to the table in MIGRATION.md so we have its new location documented there too?
💔 Build Failed |
💔 Build Failed |
💚 Build Succeeded |
|
||
this.isOpen = true; | ||
|
||
document.body.appendChild(this.container); |
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 was going to say that direct document access should probably be avoided in plugins in favor of core's rootDomElement
, but it seems we are not actually exposing it. What are the recommended guidelines for this @joshdover ? As this seems quite common, should we provide an API for plugins to create that kind of containers?
@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.
Code LGTM, looking forward to use it in my Discover PR!
@cchaos Can you take another look? I removed the unnecessary classes and it looks all good AFAICT. |
💚 Build Succeeded |
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, LGTM!
This PR moves the share registry and surrounding functionality into a separate Kibana platform plugin.
Dev docs
The
ui/share
registry is removed in favor of theshare
plugin which exposes aregister
method in the setup contract. The interface of share menu providers does not change except for the removal of angular dependency injection. The function to render the menu also moves into a function exposed by theshare
plugin in the start phase instead of a function which has to be called with the menu item providers. The following items have also been renamed:ShowProps
->ShowShareMenuOptions
ShareMenuItemProps
->ShareContext
showShareContextMenu
->toggleShareContextMenu