[Logs Explorer] Implement Flyout content header

[tonyghiani]

📓 Summary

Closes #169501

🛑 Merge blocked by: #169634

This work implements the first frame for a detailed log flyout.
It adds highlight on the log level, timestamp and message details for a log.
This first layer of customization will work as a base for all the upcoming enhancements on the flyout detail.

Screen.Recording.2023-10-26.at.10.20.49.mov

[apmmachine]

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

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

[davismcphee]

Suggested change

	Content: (props) => {
	const KibanaContextProviderForPlugin = useKibanaContextForPluginProvider(core, plugins);
	return (
	<KibanaContextProviderForPlugin>
	<LazyCustomFlyoutContent {...props} />
	</KibanaContextProviderForPlugin>
	);
	},
	Content: (props) => {
	const KibanaContextProviderForPlugin = useKibanaContextForPluginProvider(core, plugins);
	const internalState = useObservable(
	stateContainer.internalState.state$,
	stateContainer.internalState.get()
	);
	return (
	<KibanaContextProviderForPlugin>
	<LazyCustomFlyoutContent {...props} dataView={internalState.dataView} />
	</KibanaContextProviderForPlugin>
	);
	},

Instead of adding dataView to FlyoutContentProps, could we instead retrieve it from the state container directly and pass it to your custom component? I'd prefer to keep a single source of truth for customizations to access the shared state if possible.

On a side note, requiring useObservable to access our state in customization components feels a bit inconvenient IMO. Internally we use state selector functions instead, and we could likely give customizations access to the same selectors by passing them to the CustomizationCallback. Just curious if it would be useful for your team to have access to these selectors too?

[tonyghiani]

Hey Davis, our team is working on extracting the persistent system on top of the state container, so that each consumer of the log explorer won't depend on the URL sync. I think we'll consume the internal state reacting to the observable changes anyway, I can't say if we'll need those selectors.

Regarding your suggestion I see your point, I'll apply your suggestion and revert the changes on the customization contract.

[tonyghiani]

Changes applied in c0cf9dc

[tonyghiani]

/oblt-deploy

[davismcphee]

Code-only review. Data Discovery changes (now just some type exports) LGTM 👍

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 46507aa

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
logExplorer	455	462	+7

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
discover	77	87	+10

Async chunks

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

id	before	after	diff
logExplorer	195.1KB	201.1KB	+6.0KB

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id	before	after	diff
@kbn/unified-doc-viewer	6	7	+1
discover	19	18	-1
total			-0

Page load bundle

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

id	before	after	diff
logExplorer	35.6KB	36.4KB	+813.0B

Unknown metric groups

API count

id	before	after	diff
discover	120	130	+10

async chunk count

id	before	after	diff
logExplorer	5	6	+1

ESLint disabled line counts

id	before	after	diff
logExplorer	4	5	+1

Total ESLint disabled count

id	before	after	diff
logExplorer	6	7	+1

History

• 💔 Build #172701 failed aa8bf51
• 💛 Build #172223 was flaky bb11af7
• 💛 Build #172183 was flaky 09e3cf6
• 💔 Build #172162 failed cabb230
• 💔 Build #172129 failed c1f97d6

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

[mohamedhamed-ahmed]

LGTM! Clean work 👏 Tested it and works great
Thanks for adding the tests