-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
New platform migration guide #31147
New platform migration guide #31147
Conversation
Pinging @elastic/kibana-platform |
|
||
Different service interfaces can and will be passed to `setup` and `stop` because certain functionality makes sense in the context of a running plugin while other types of functionality may have restrictions or may only make sense in the context of a plugin that is stopping. | ||
|
||
For example, the `stop` function in the browser gets invoked as part of the `window.onbeforeunload` event, which means you can't necessarily execute asynchronous code here in a reliable way. For that reason, `core` likely wouldn't provide any asynchronous functions to plugin `stop` functions in the browser. |
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.
imho it makes sense to start Plugin introduction from lifecycles and describe their signature. Don't see any start
mentions in the doc
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.
To clarify, do you mean that you'd like to have a description in this document of the three lifecycle functions and how lifecycle functions work in general?
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.
- list of lifecycles
- their meaning
- their signature
- their calling order
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 agree that this would be valuable context. It would also be good to include the plugin factory function in the lifecycle calling order.
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 pushed more information about lifecycles with a focus on relevant information for the sake of migration 5d343de
- Add missing return statement highlighted during meeting. - `apiExport` -> `uiExport` - Small spelling check
{ | ||
"id": "demo", | ||
"server": true, | ||
"ui": true |
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 it's much easier to understand and build up a mental model if the configuration option key is consistent with other naming conventions. Both should be ui
or both public
etc.
To dig up an old discussion, although /public
is a strong convention for a folder structure, it's much less intuitive as a configuration option or as code e.g. PublicStartContract
or "public": true
(appears to be a visibility setting?). It's also unnatural to talk about "public code", we're more likely to say "client-side code" or "ui code".
So I'd prefer if we change public
-> ui
.
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 going to leave this as-is in the guide for now since ui
is what exists, but feel free to open an issue to discuss this separately.
|
||
Different service interfaces can and will be passed to `setup` and `stop` because certain functionality makes sense in the context of a running plugin while other types of functionality may have restrictions or may only make sense in the context of a plugin that is stopping. | ||
|
||
For example, the `stop` function in the browser gets invoked as part of the `window.onbeforeunload` event, which means you can't necessarily execute asynchronous code here in a reliable way. For that reason, `core` likely wouldn't provide any asynchronous functions to plugin `stop` functions in the browser. |
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 agree that this would be valuable context. It would also be good to include the plugin factory function in the lifecycle calling order.
{ | ||
"id": "demo", | ||
"server": true, | ||
"ui": true |
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.
version
appears to be a required property, we might want to include "version": "8.0.0"
in the example?
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.
Since no plugin is quite ready to completely migrate today, I'm going to proceed as-is for now, but I'll follow up with this separately. We do still want external plugins to specify a version property, but I want to remove the requirement that new platform plugins in the Kibana repo require a version property.
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.
Issue for this: #34660
I just re-read and it all makes sense to me. Only (non-urgent) suggestions I would add are:
|
@lukeelmers Those are both great suggestions. I'm going to hold off adding them to this PR so it can go in, but they're good improvements to add to the doc in followups. |
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 investing the time to do this; it's going to be a huge help for the rest of the team.
💚 Build Succeeded |
Latest guide rendered here: https://github.com/elastic/kibana/blob/602091982d2d1c48ad464304f1e05b65d98f14a5/src/core/MIGRATION.md