Change progress bar to spinner

[ryankeairns]

Summary

With the implementation of navigational search, the global progress bar became even more noticeable due to the frequent loading nature of the typeahead interaction. In other words, the pink progress bar flashes constantly as you type and it's rather distracting. This PR converts the current loading bar to a spinner that appears within the new stacked header (alongside the logo).

Before

After

Keeping the progress bar option for full screen mode

Same look as before but with EuiProgressBar

Related changes in this PR

Single loading indicator on initial screen

A nice side effect of moving the loading indicator into the header is that we avoid having two loading elements on the initial loading screen. Notice the absence of the pink progress bar below:

Animated cluster between apps

Beyond the initial loading screen, an additional spinner (not the Elastic logo) could occasionally be seen in the body of the page. To avoid having the same spinner within the header and the page, I've changed the page spinner to use the animated cluster (EuiLoadingElastic). This one appears less frequently due to the new platform (thankfully), but here's a glimpse:

Minimize loading 'flashes'

Lastly, I have also tuned the debounce setting to further reduce the number of spinner flashes seen as you type in the search input. Compared to the 'Before' gif atop this issue, you'll see the results panel no longer flickers as well.

---

Implementation notes

• I chose to use an aria-hidden: true approach - coupled with visibility: hidden - in order to preserve the real estate used by the spinner in the header. This prevents the search input from jumping around as it would if the spinner was hidden via display: none , for example.
• The spinner continues to animate even while hidden, so I have also added a animation-play-state: paused rule. I couldn't live with this, even if it's not visible:
  

Checklist

Delete any items that are not applicable to this PR.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for keyboard-only and screenreader accessibility
• This was checked for cross-browser compatibility

[ryankeairns]

jenkins test this

[elasticmachine]

Pinging @elastic/kibana-core-ui (Team:Core UI)

[elasticmachine]

Pinging @elastic/kibana-design (Team:Kibana-Design)

[pgayvallet]

@ryankeairns is the interaction with the searchbar the main reason for this change? If so, we could add an option to http.fetch to not show the loader for a specific request.

(If it was also planned for other reasons, just forget about the proposition)

[ryankeairns]

@ryankeairns is the interaction with the searchbar the main reason for this change? If so, we could add an option to http.fetch to not show the loader for a specific request.

(If it was also planned for other reasons, just forget about the proposition)

@pgayvallet Thanks for the option. There has been clamoring (on the design side, at least) to improve the pink progress bar for some time and, yes, the new search feature made it even more visible. The loading indicator is useful for search, imo, so I've opted to try this new approach.

[ryankeairns]

jenkins test this

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: d29dd8a

Metrics [docs]

page load bundle size

id	value	diff	baseline
core	1.1MB	-2.8KB	1.1MB

History

• 💔 Build #77579 failed 329c38e
• 💔 Build #77395 failed 329c38e
• 💚 Build #77241 succeeded efc5801
• 💔 Build #77228 failed ede0a37
• 💔 Build #77208 failed f2ef2ba

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

[cchaos]

Pretty elegant solution! Quick question, how will this now work when we eventually have either an OSS or deployment badge next to the Elastic brand? Are you good with the extra space that would create? Or are you thinking that we're now restricting additional header elements to the right side only?

[ryankeairns]

Pretty elegant solution! Quick question, how will this now work when we eventually have either an OSS or deployment badge next to the Elastic brand? Are you good with the extra space that would create? Or are you thinking that we're now restricting additional header elements to the right side only?

Thanks for the review!

My thought was that the deployment switcher winds up on the right side. It's been presented both ways and, frankly, I'm not sure when this will get added at the current pace.

We have some flexible options for the OSS badge. For example, we could flip back to the progress bar (via the new showAsBar prop) since it does not have search. If we end up showing badges beyond OSS, then we may have to play with the layout.

There is a third consideration here, too, and that is the async stuff that DeFazio is working on in the breadcrumb area. We chatted and can/will avoid displaying two loading spinners.

Overall, this PR is a low investment refactoring of the current loading indicator code that could be easily be changed if/when those other things come along in the future.

[cchaos]

I 100% agree this is a much needed upgrade. Just wanted to know if you'd thought out that badge placement or if that is a thing of the past. We tend to shift content around on the user a lot and wanted to see if we could avoid that here. I'd probably resist changing back to the progress bar just for OSS, seems like an odd distinction/difference to make. But in that case the extra space is probably fine. 👍 😍