[Lens] allow user to disable auto apply

[drewdaemon]

Summary

Allows user to disable Lens's current auto-apply behavior. This enables them to save on resources associated with rendering a complex or large visualization.

Screen.Recording.2022-02-15.at.4.10.50.PM.mov

With full-screen datasource

Resolves #74490

Filters and suggestions are still applied automatically. Open for feedback here.

[flash1293]

This looks really good to me.

There's one "bug" I found:

kibana/x-pack/plugins/lens/public/state_management/context_middleware/index.ts

Line 25 in 1185a33

updateTimeRange(storeDeps.lensServices.data, store.dispatch);

is updating the search session id and the time range which is implicitly applying and sending out another request. To reproduce, set current time range to 15mins, turn off auto apply and wait for 20 seconds, then do a change - it will be applied automatically. I suggest we just turn off this "outdated now" behavior as long as auto apply is not active.

One behavior I found a bit strange: Changing query/filter/timerange is reloading the chart (which is expected), but it's also auto-applying all changes made to the config in the meantime. This is theoretically fine, but it's different than TSVB and Visualize agg based behavior and IMHO it's closer to what a user would expect. cc @ghudgins @MichaelMarcialis what do you think?

[drewdaemon]

[the app is] updating the search session id and the time range which is implicitly applying and sending out another request. To reproduce, set current time range to 15mins, turn off auto apply and wait for 20 seconds, then do a change - it will be applied automatically. I suggest we just turn off this "outdated now" behavior as long as auto apply is not active.

Thanks for pinning this down. I had seen the behavior but hadn't yet been able to reproduce reliably. This has been addressed so that, while auto-apply is disabled, the time range is only updated when the user applies changes.

One behavior I found a bit strange: Changing query/filter/timerange is reloading the chart (which is expected), but it's also auto-applying all changes made to the config in the meantime. This is theoretically fine, but it's different than TSVB and Visualize agg based behavior and IMHO it's closer to what a user would expect.

I don't think anyone objected to this last week during my demo at the vis-editors sync, but I still agree with you that it could be unexpected behavior. After digging into it a bit, I found that this behavior is due to syncExistingFields being fired when we get new active data. I had to make it so that it immediately applies changes because otherwise I ran into the following problem:

• user has auto-apply disabled in localStorage
• navigates to Lens editor
• syncExistingFields gets called when data loads
• apply button turns blue before user has changed anything

It isn't clear how to address both of these issues. Any ideas?

[MichaelMarcialis]

One behavior I found a bit strange: Changing query/filter/timerange is reloading the chart (which is expected), but it's also auto-applying all changes made to the config in the meantime. This is theoretically fine, but it's different than TSVB and Visualize agg based behavior and IMHO it's closer to what a user would expect. cc @ghudgins @MichaelMarcialis what do you think?

Per our discussion in today's vis editors sync, I think the current implementation (auto-applying all changes when a query/filter/date picker change is made) makes sense given that the reason to add this feature was to provide users an option that avoids having to perform multiple, performance-heavy re-renderings of the visualization. Applying only query/filter/date picker changes and no other changes asks that users also apply and re-render their visualization a second time, which goes against that original intent.

[drewdaemon]

@elasticmachine merge upstream

[stratoula]

The options on the top work fine now except from one! If I have defined a custom axis name such as here:

and clear the value, the apply button is not enabled:

[drewdaemon]

@stratoula thanks for the catch. I fixed it 👍

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 74a3dbd
• Storybooks Preview
• Webpack Bundle Analyzer

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
lens	1.1MB	1.1MB	+5.0KB

Unknown metric groups

ESLint disabled line counts

id	before	after	diff
lens	37	41	+4

Total ESLint disabled count

id	before	after	diff
lens	39	43	+4

History

• 💚 Build #27205 succeeded be329a3
• 💚 Build #27090 succeeded 80f9f1e
• 💔 Build #27020 failed 41d8e8e
• 💚 Build #26948 succeeded a5493e6
• 💔 Build #26920 failed d6ba1db
• 💚 Build #26819 succeeded 8a850f0

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

[stratoula]

LGTM! I tested it once again and I can't find other bugs. Thanx @andrewctate for applying all the comments! 🥇

[kibanamachine]

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create backports run node scripts/backport --pr 125158 or prevent reminders by adding the backport:skip label.