-
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
Clear core loading indicator just before UI is rendered #55242
Conversation
Pinging @elastic/kibana-platform (Team:Platform) |
MockNotificationsService.start.mockImplementation(({ targetDomElement }): any => { | ||
expect(targetDomElement.parentElement).not.toBeNull(); | ||
targetDomElementParentInStart = targetDomElement.parentElement; |
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.
AFAIK it does not actually matter that the DOM element passed to Notifications is attached to the root element when NotificationsService#start
is called, as long as it is attached at some point.
In the future, this pattern should probably be replaced by the single React-tree pattern provided by RenderingService that ChromeService and ApplicationService leverage.
Do we know which changes actually did? EDIT: nevermind, #55241 |
@elasticmachine merge upstream |
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Summary
This delays hiding the loading indicator until right before Core renders the basic UI (chrome, notifications, etc.)
This change should probably be backported to 7.6, where many of the changes that increased this load time were introduced.
This eliminates the problem where a blank screen is shown to the user while Core is running it's startup sequence. Note that I also found other opportunities to improve client-side startup performance here: #55241