[lens] immediately display loading panel when adding new ES|QL panel

[nreese]

Problem

"Add new ES|QL panel" action awaits several network requests before showing a new panel. This makes Kibana feel clunky as the UI does not immediately respond to user actions. Follow the test instructions on main to see the problem.

Solution

"Add new ES|QL panel" action updated to immediately call parentApi.addNewPanel when "Add new ES|QL panel" action is executed, thus providing immediate user feedback by displaying a loading panel. Network requests to build default ES|QL lens state are moved into buildEmbeddable.

Test instructions

1. open new dashboard
2. set network speed to "slow 4g".
3. Click "Add panel"
4. Click "ES|QL"
5. Verify user is given immediate feedback by displaying loading panel before any awaits occur.

cc @stratoula @dej611

[nreese]

/ci

[elasticmachine]

💔 Build Failed

• Buildkite Build
• Commit: c2c961a

Failed CI Steps

• Linting
• Check Types

History

[nreese]

/ci

[elasticmachine]

Pinging @elastic/kibana-visualizations (Team:Visualizations)

[stratoula]

I did a very brief testing and this looks significantly faster. Thanx @nreese for working on this 🙌

[dej611]

While I agree on the final goal, I think the solution here is not exactly what I was expecting.
I would expect the initializers to be sync code that simply creates all the right things to watch before calling the loader at the end.

In the ES|QL scenario I understand there's some extra async preparation for this, so we're forcefully forwarding the async behaviour into the entire lens embeddable stack and make everything async.
Why not change this into a simpler flow?

• add new panel const embeddable = addNewPanel(...)
• call to update the attributes once done: embeddable.updateAttributes(esqlAttributes);
• call to onEdit: embeddable.onEdit()

Maybe a the loading state until the update call is reached can be communicated in the parentApi somehow, but it would be a bit cleaner to me.
What do you think @nreese ?

[nreese]

buildEmbeddable is async because initializing an embeddable will likely require async actions. For example, many embeddables load a dataView.

When buildEmbeddable returns, the embeddable is initialized. I don't think it makes sense to add complexity to parentApi to add a work around for this.

For lens, we could keep initializeInternalApi sync and do something like the below. Would that resolve your concerns?

const internalApi = initializeInternalApi(
  initialState: {
    ...initialState,
    attributes: 
      initialState.isNewPanel
      ? await createNewEsqlAttributes(services)
      : initialState.attributes,
  },
  parentApi,
  titleManager,
  services
);

[dej611]

What I mean is that we could move the await createNewEsqlAttributes(services) into the loader code. No?

[nreese]

I am not familiar with loader code. Can you provide a file reference and maybe a pointer to where you are thinking. Some sample code would help

[nreese]

replacing with #210084