[Logs UI] Support inline Log Views in the UI

[Kerry350]

Summary

This closes #142840. It is the UI portion of support for inline Log Views.

Visible changes to the UI

ML warning

Alert dropdown warning

Settings page warning

Reviewer hints / notes

• The ACs on the issue are quite extensive and should provide a good number of things to test.

  • Make use of the "playground" page (see below) to make this easier

• The AlertDropdown has been made lazy as the page load bundle increased by 100kb otherwise.

• Our link-to functionality is scoped to persisted Log Views only at the moment as historically they've only accepted a path segment, not full query parameters. We can look to extend this in the future once we have concrete linking needs.

Questions

• I have allowed the Log View client to handle both the inline and persisted Log Views. I wonder if the function names become confusing? (e.g. are the RESTful prefixes misleading now?).

• The ML warning splash page links to settings to revert to a persisted Log View. It could also be done in place on the page. I went back and forth over whether we should keep the reverting in one place?

Testing

There is now a "state machine playground" available at the following URL: /app/logs/state-machine-playground, it is enabled in developer mode only. It's not fancy or pretty it just serves to make testing things easier. There are various buttons, e.g. Switch to inline Log View, to facilitate easier testing whilst a Log View switcher is not in the UI itself. You can utilise these buttons, and then head to other pages to ensure things are working correctly, e.g. warning callouts and disabled buttons etc. If you'd like to play with the options used, e.g. for update, amend the code within state_machine_playground.tsx. It's also useful just to sit on this page, try various things, and verify what happens in the developer tools (does the context update correctly etc).

Known issues

• When saving on the settings page we actually revert to a "Loading data sources" state. This is also the case on main. The reason for this is the check within settings looks like so:

if ((isLoading || isUninitialized) && !resolvedLogView) {
    return <SourceLoadingPage />;
}

but the resolvedLogView state matching looks like so:

const resolvedLogView = useSelector(logViewStateService, (state) =>
    state.matches('checkingStatus') ||
    state.matches('resolvedPersistedLogView') ||
    state.matches('resolvedInlineLogView')
      ? state.context.resolvedLogView
      : undefined
  );

so even though we have resolved a Log View previously the state matching overrides this. I'd prefer to follow this up in a separate issue as I'd like to think through the ramifications a bit more. It's not a bug, but it is jarring UX.

[elasticmachine]

Pinging @elastic/infra-monitoring-ui (Team:Infra Monitoring UI)

[Kerry350]

@elasticmachine merge upstream

[tonyghiani]

It's a great job Kerry, congrats! 👏

I found the visual implementation to work well and the playground you added is awesome for testing purposes!

One thing I notices and I'm not sure if it is the expected behaviour, is once you apply directly on the URL the logView=(id:playground-log-view,type:log-view-inline) parameter, it fails and notify of a validation error because the attributes are missing, here a quick demo:

inline-log-view.mov

The ML warning splash page links to settings to revert to a persisted Log View. It could also be done in place on the page. I went back and forth over whether we should keep the reverting in one place?

I personally believe that for users the shortest path would be the best UX.
If there is nothing more they can do except switch back to a persisted log view to enable the ML page, I'd rather give them the call to action directly on the page, with no need to leave it to reach the settings and click another button.

I also left a couple of comments but are minor things and not-blocking 👍

[Kerry350]

@tonyghiani

Thank you for the review 🙏

One thing I notices and I'm not sure if it is the expected behaviour, is once you apply directly on the URL the logView=(id:playground-log-view,type:log-view-inline) parameter, it fails and notify of a validation error because the attributes are missing

This is the expected behaviour for now. If we start out strict we can potentially relax things (validation wise) in the future if we need to. It's hard to tell exactly what our needs might be as we're not directly exposing any of this in the UI yet, but staying strict (and requiring a complete type) simplifies things for now.

I personally believe that for users the shortest path would be the best UX.
If there is nothing more they can do except switch back to a persisted log view to enable the ML page, I'd rather give them > the call to action directly on the page, with no need to leave it to reach the settings and click another button.

Sounds good to me, I'll change this 👍

[Kerry350]

@tonyghiani Pushed all of the changes discussed 👍

[tonyghiani]

LGTM, thanks for the quick changes 👏

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 665a459

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
infra	1292	1296	+4

Async chunks

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

id	before	after	diff
infra	1.4MB	1.4MB	+9.8KB

Page load bundle

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

id	before	after	diff
infra	88.3KB	86.8KB	-1.4KB

Unknown metric groups

async chunk count

id	before	after	diff
infra	25	26	+1

ESLint disabled line counts

id	before	after	diff
infra	48	49	+1
securitySolution	433	436	+3
total			+4

Total ESLint disabled count

id	before	after	diff
infra	56	57	+1
securitySolution	513	516	+3
total			+4

History

• 💔 Build #116331 failed f1e8b3b
• 💔 Build #116063 failed a1fa8fd
• 💚 Build #113922 succeeded 2fb2844
• 💚 Build #113325 succeeded 9beb153
• 💚 Build #113135 succeeded 4ab9bd5

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

cc @Kerry350