-
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
[New platform]Expose NP core services to the legacy UI #32480
Conversation
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.
Good stuff. One thing though: while stop doesn’t seem necessary, I think we will be adding a separate init lifecycle event alongside start, and both of those contracts will be relevant to legacy plugins.
This isn’t 100% final yet, but perhaps it is worth identifying these apis as “start” so folks don’t need to update their code as much when init happens.
throw new Error('New platform api was already initialized'); | ||
} | ||
|
||
runtimeContext.core = Object.freeze(core); |
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 found several deepFreeze
implementation in our code base. Should we have a dedicated package/wheterver for this?
💚 Build Succeeded |
196b20e
to
1dccd0c
Compare
💚 Build Succeeded |
@epixa should we add integration tests here? We can test only getter logic, which is not really useful. |
@restrry I don't think we should integration test the ui module shims |
Pinging @elastic/kibana-platform |
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
I added a couple comments/nits. I'm curious why we need the duplication with the RuntimeContext, which I commented on. It would be great if we could limit that kind of duplication, but it's non-critical.
chrome: ChromeStart; | ||
} | ||
|
||
interface RuntimeContext { |
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.
question: Is the whole reason we need this interface because of the conditional existence of start.core
?
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.
yes. as an alternative we can cast type right in place.
const runtimeContext = {
start: {
core: null as StartCore | null,
💔 Build Failed |
💚 Build Succeeded |
* Expose NP core services to the legacy UI * declare start/stop explicitly * simplify typings + renaming
💔 Build Failed |
💔 Build Failed |
Summary
#32395
Expose NP core services to the legacy UI platform. There are no plugins to include yet.
Checklist
Use
strikethroughsto remove checklist items you don't feel are applicable to this PR.[ ] This was checked for cross-browser compatibility, including a check against IE11[ ] Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support[ ] Documentation was added for features that require explanation or tutorials[ ] Unit or functional tests were updated or added to match the most common scenarios[ ] This was checked for keyboard-only and screenreader accessibilityFor maintainers
[ ] This was checked for breaking API changes and was labeled appropriately[ ] This includes a feature addition or change that requires a release note and was labeled appropriatelyDev Docs
Expose NP core services to the legacy UI
Kibana is in process of stabilising of API. The client side core services are quite different from existing ones and were heavily refactored. If you want to play around with experimental API use
where
newPlatform
exposes: