Skip to content
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

Merged
merged 2 commits into from
Jan 21, 2020

Conversation

joshdover
Copy link
Contributor

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

@joshdover joshdover added Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Feature:New Platform release_note:skip Skip the PR/issue when compiling release notes v7.6.0 labels Jan 17, 2020
@joshdover joshdover requested a review from a team as a code owner January 17, 2020 21:56
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-platform (Team:Platform)

MockNotificationsService.start.mockImplementation(({ targetDomElement }): any => {
expect(targetDomElement.parentElement).not.toBeNull();
targetDomElementParentInStart = targetDomElement.parentElement;
Copy link
Contributor Author

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.

@pgayvallet
Copy link
Contributor

pgayvallet commented Jan 20, 2020

This change should probably be backported to 7.6, where many of the changes that increased this load time were introduced.

Do we know which changes actually did?

EDIT: nevermind, #55241

@joshdover
Copy link
Contributor Author

@elasticmachine merge upstream

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@joshdover joshdover merged commit b0af1bf into elastic:master Jan 21, 2020
@joshdover joshdover deleted the np/fix-core-loading branch January 21, 2020 16:19
joshdover added a commit to joshdover/kibana that referenced this pull request Jan 21, 2020
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
joshdover added a commit to joshdover/kibana that referenced this pull request Jan 21, 2020
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:New Platform release_note:skip Skip the PR/issue when compiling release notes Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc v7.6.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants