[APM] Service Maps: Loading states on map initiation and while rendering

[formgeist]

Summary

From the time a user enters the view the first time until we have a complete interactive map may take a few moments. To improve the UX and allow for a more progressive load experience, we're suggesting to implement a simple progress loader to indicate from start to end of render.

Design

This implementation will temporarily lock the map interactions and hide the controls in order not to create any unnecessary jank for the user if they were to interact and open popovers while the map continues to load. Once we deem the map has finished rendering, we will unlock and unhide the controls.

[elasticmachine]

Pinging @elastic/apm-ui (Team:apm)

[dgieselaar]

I'm not sure if we should optimize for the full load. The initial request ideally resolves in max 4-5s, but then successive requests could take 10-30s each, and are unlikely to create new connections. I think @smith's suggestion is a good one: show perhaps a small loader after the initial request has loaded, and then offer the user a toast with an update/refresh button only if successive requests deliver previously undiscovered connections.

[formgeist]

Sure - I think we discussed a more sophisticated loading scenario where we'd simply allow the user interactions if the requests have not returned any new connections in the last 1-2 seconds, as we won't expect there'd be any new connections coming in after that period of time. I think it needs fine-tuning, but in either case we need a loading screen with some information for the user, and I think the hide controls and lock/dimming the begin with helps the user not go into unnecessary clicks and interactions because the map is still loading. WDYT?

[dgieselaar]

Hmm, just feels like we don't need to lock the map if we only update the map when the user explicitly asks the UI to do so. Any heuristic to decide whether we should or should not expect changes from additional requests is just guesswork anyway. As in, the time it takes to resolve the slower, more accurate requests does not say a lot about whether it will return new connections. I think deferring control to the user about when to update the UI is a good principle in this case. So I'd opt to just have a toast/button if there are new connections found (I expect that to be an exception anyway). Just my 2c of course

[formgeist]

Initial implemented and closed by #54027