[Console] Progress bar - #56628

Can we use a class name here instead? I'm not sure if our CSP disallows inline styles, but I think we are moving in that direction.

That's an interesting point! Do you know whether this is the current CSP src/core/server/csp/config.ts?

Oh cool, didn't know about that file! I'm not sure but it looks like it would be.

Can we use an EuiFlexGroup to handle layout instead of custom classes?

Originally, I did use an EuiFlexGroup, but found the padding on bottom and top too big. Given your suggested changes below I am happy to change this!

Is conApp__outputNetworkRequestStatusBar__badge defined anywhere?

Also if we remove the conApp__outputNetworkRequestStatusBar__item class and set gutterSize="s" on the EuiFlexGroup on line 63, we'll get this layout which I think looks a bit better:

Will clean that up!

I'm trying to understand why this file was changed. Was this line the only material change?

Mainly it was convernted to .ts. That particular change is for the this object of the callback handler - which should actually not be anything.

Thanks!

It looks like the location of this component causes some rendering problems when you open the "History" dropdown:

In terms of component hierarchy, I'd also expect to find it located near the tabs in the code, since it's located near the tabs visually. If we change https://github.com/elastic/kibana/blob/master/src/plugins/console/public/application/containers/main/main.tsx#L70 to this:

        <EuiFlexItem grow={false}>
          <EuiTitle className="euiScreenReaderOnly">
            <h1>
              {i18n.translate('console.pageHeading', {
                defaultMessage: 'Console',
              })}
            </h1>
          </EuiTitle>

          <EuiFlexGroup gutterSize="none">
            <EuiFlexItem grow={false}>
              <TopNavMenu
                disabled={!done}
                items={getTopNavConfig({
                  onClickHistory: () => setShowHistory(!showingHistory),
                  onClickSettings: () => setShowSettings(true),
                  onClickHelp: () => setShowHelp(!showHelp),
                })}
              />
            </EuiFlexItem>

            <EuiFlexItem className="conApp__tabsExtension">
              <NetworkRequestStatusBar
                method={'GET'}
                endpoint={'/the_last_starfighter'}
                statusCode={200}
                statusText={':)'}
                timeElapsedMs={'411'}
              />
            </EuiFlexItem>
          </EuiFlexGroup>
        </EuiFlexItem>

And add this class somewhere:

.conApp__tabsExtension {
  border-bottom: $euiBorderThin;
}

Then the rendered output is correct and the two components will be colocated:

Awesome! Happy with these changes, I was a bit stuck on this one 👍

What do you think of hiding the second badge and replacing this one with a hollow one that says "Request in flight" while the request is in flight? I think it improves usability by 1) acting as a placeholder for the request results so you know where to look for them and 2) explaining the purpose of the strobing progress indicator.

I might be missing something, but I think this condition introduces a UX problem. Current behavior in master is that the latest request supersedes older in-flight requests. So, if you have a long-running request and then dispatch a new request, it will appear as if the long-running request was cancelled because the new request's response will appear instead. This is useful in case you get frustrated with a long-running request and want to try something different.

With the change made here, the user is forced to sit through a long-running request and has to reload Console to "cancel" it. Was there another problem this change was intended to fix?

You are totally correct, this is an artefact that should have been removed!!

I feel like the way this is represented in the UI isn't particularly useful. I didn't actually send a request to an endpoint, and there was no real response nor elapsed time, so this information in the top-right corner doesn't seem relevant:

Can we explore ways to make this more useful? How about we preserve the existing information from the prior request (i.e. the response payload in the output pane as well as the status and elapsed time badges), and instead just show a neutral toast to let the user know that they need to move their cursor inside of a request or highlight multiple requests in order to execute them?

I would just remove this empty space.

I would also remove this empty space.

Nit: I think our copywriting guide discourages phrases like "it looks like" and niceties like "please". My suggestion is: "No request selected. Select a request by placing the cursor inside it."