[Logs+] Restore Dataset selection from page URL

[tonyghiani]

📓 Summary

Closes #160425

After the first implementation of the log-explorer profile, we wanted to restore the selection of the dataset for a user when landing on the Discover log-explorer profile.

Since we create an ad-hoc data view for Discover starting from the dataset details, we needed to develop a system for intercepting the index query parameter (which is used by Discover as the source of truth for restoring a data view), create our ad-hoc data view and store in the URL an encoded ID with the required details to restore the selection.

The following video shows the user journey for:

• Landing on the log-explorer profile with no index param, nothing to restore and fallback to All log datasets.
• Landing on the log-explorer profile invalid index param, notify about failure and fallback to All log datasets.
• Select a different dataset, applies the new data view and update the URL. When the URL is accessed directly, restore and initialize the data view for the selection.
• Navigate back and forth in the browser history, restoring the selection and data view on index param changes.

restore-dataset.mov

💡 Reviewer hints

To have better control over the page selection and the restore process, we prepared the DatasetSelector component for being controlled by the parent component.
Having that ready, we now implemented a new top-level state machine with the following responsibilities:

• Re-initialize (decompress/decode) the dataset selection from the index query params.
• Derive and set into Discover state a new ad-hoc data view.
• Keep track of new dataset selection changes and update the URL state and the current data view.

We found a race condition between the Discover URL initialization + data view initialization against the log-explorer profile customizations being applied.
To guarantee we correctly initialize the state machine and restore the selection before Discover goes through its initialization steps, we need to wait for the customization service to exist in Discover so that also the customization callbacks are successfully invoked.

[apmmachine]

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

• /oblt-deploy : Deploy a Kibana instance using the Observability test environments.
• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[davismcphee]

I appreciate the effort to make the initialization steps more explicit, but to be honest I think I preferred your original approach (although maybe moving the isCustomizationServiceInitialized check to the initialization useEffect rather than within loadSavedSearch itself to make the initialization steps clearer).

The idea behind useDiscoverCustomizationService was to encapsulate the lifecycle of the customization framework behind a single hook rather than having the main Discover code manage it. This way the framework lifecycle can be tested as a single hook, it has a limited footprint within the Discover codebase, and it's portable enough to be moved/removed later if needed.

While the changes here are limited, I worry that starting to mix the customization framework with the main Discover code could create dependencies that become harder to remove over time. Ideally discover_main_route's only interaction with the customization framework would be to delay loading Discover until the service exists, at which time it can be guaranteed that the customization framework is initialized and Discover is safe to load.

[tonyghiani]

Hey @davismcphee, thanks for the in-depth review! I appreciate you explaining the downside of the approach I proposed for initializing the flow, and I can see all of them and agree with you.
To avoid mixing it up and complicating the flow, I switched back to the original approach using the flag for waiting for the effect to run, everything keeps working as expected and I don't want to block the PR reviewers too much.

Switching back to the original approach should resolve all the other suggestions you left.

Thanks again for the review!

[davismcphee]

Thanks for understanding my concerns, and with the latest updates this looks good to go on my end. I also tested and confirmed Discover is working as expected and Logs Explorer dataset selections are preserved on refresh. Thanks for fixing the Discover initialization bug too! LGTM 👍

[mohamedhamed-ahmed]

Reviewed and Tested the infra changes! LGTM overall
Thanks for adding the tests, let us discuss afterward how to use the stateContainer and merge our work together ! 🚀

[mohamedhamed-ahmed]

nit: TypeState

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 8fe91cc

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
discoverLogExplorer	140	149	+9

Async chunks

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

id	before	after	diff
discover	546.4KB	546.5KB	+92.0B
discoverLogExplorer	192.9KB	197.9KB	+5.0KB
total			+5.1KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
discoverLogExplorer	4.4KB	4.5KB	+105.0B

Unknown metric groups

async chunk count

id	before	after	diff
discoverLogExplorer	5	7	+2

ESLint disabled in files

id	before	after	diff
discoverLogExplorer	3	2	-1

Total ESLint disabled count

id	before	after	diff
discoverLogExplorer	6	5	-1

History

• 💚 Build #143602 succeeded f736edf
• 💔 Build #143592 failed d97e26c
• 💔 Build #143581 failed 42f029d
• 💚 Build #143534 succeeded 65b44fa
• 💚 Build #143420 succeeded 4773ab7
• 💚 Build #143122 succeeded 0da335d

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