[Lens] Add loading indicator during debounce time

[flash1293]

This PR adds a loading indicator to the suggestions during the debounce time so they don't look stale

Old:

New:

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[wylieconlon]

The behavior does work as expected, but I have a suggestion for a different way of organizing the code.

[wylieconlon]

I agree that this approach works, but does it need to be Lens-specific? What if we supported a debouncing parameter on the ExpressionRenderer component which would handle this automatically? The main reason I'm suggesting this is that the ExpressionRenderer component is already responsible for showing both an EuiProgress and <EuiLoadingChart size="m" />, and it might be easy to share the logic.

[flash1293]

@elastic/kibana-app-arch what do you think about having a “debounce” parameter on the expression renderer component basically replicating this logic one layer deeper? The use case here is to not re-render the suggestions too often while the user interacts with the config, but still show an indication the current state will be updated soon.

[ppisljar]

i don't see a problem with introducing debounce parameter to expression renderer component

[flash1293]

Thanks Peter, I will move the logic over on this PR

[flash1293]

I moved the logic for debouncing into the react expression renderer component.

[flash1293]

Huh, I thought the react hooks package was already part of the bundle. I will look into a replacement

[wylieconlon]

Code LGTM, tested locally in Lens. I don't think there are any uses of this component outside Lens.

[wylieconlon]

Did not test since my last review, but I'm surprised about the react-use issue.

1. Lens and other plugins are already importing react-use
2. APM is importing it via import useDebounce from 'react-use/lib/useDebounce';
3. Ingest manager has a custom definition of useDebounce separately from these

I'm fine with the choice to define an effect instead of increasing the import size, but I wonder if it would be simpler to accept the entire react-use package as a shared dependency.

[flash1293]

@elasticmachine merge upstream

[flash1293]

@wylieconlon I considered something along those lines, but it's not super straight forward, that's why I opted for the inline implementation:

• By default, npm dependencies become part of each individual plugin bundle
• The other plugins using it are doing so in async bundles, but this component is part of the initial bundle
• We could move it to the shared dependencies, but AFAICT it would be the only place where it's used in the initial bundle, so it would still bloat the total initial JS download size compared to the current baseline
• We could make this usage async as well by making the expressionrenderer component lazy, but that felt weird because it would mean creating a new async chunk with just that single component (which means another roundtrip until a Lens vis can be rendered)

For this use case I'm in favor of proceeding with the inline implementation as it's really straight forward and easy to read.

[kibanamachine]

💚 Build Succeeded

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

Metrics [docs]

async chunks size

id	before	after	diff
lens	1.0MB	1.0MB	-101.0B

page load bundle size

id	before	after	diff
expressions	179.3KB	180.0KB	+704.0B

History

• 💚 Build #83872 succeeded bd95db5
• 💔 Build #83399 failed d724dd4
• 💔 Build #83385 failed 3372a82
• 💚 Build #81113 succeeded 56bb095
• 💚 Build #81069 succeeded e5adad9

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

[Dosant]

I'm fine with the choice to define an effect instead of increasing the import size, but I wonder if it would be simpler to accept the entire react-use package as a shared dependency.

@wylieconlon I've created an issue: #80181

[Dosant]

app-arch debounce code changes LGTM
didn't test
Issue for addressing react-use: #80181