[Logs UI] Analyze page and URL state

[Kerry350]

⚠️ This issue will be refined as we go and plan out the state that we desire

Summary

The Log stream currently uses a selection of custom hooks and useState calls that, when trying to work together in a co-ordinated manner, becomes very confusing to follow. This issue covers the work and desired output of moving to a Redux Toolkit based solution.

Page state

Page state will be handled via XState state charts.

Data

values	has loading state	in URL / local storage
log view id	❌	✅
log view	✅	❌
query	❌	✅
filters	❌	✅
data view	✅	✅
time range	❌	✅
auto refresh	❌	✅
log entries	✅	❌
histogram data	✅	❌
highlight parameters	❌	✅
highlight data	✅	❌
visible log entries	❌	✅
display parameters	❌	✅
fly-out parameters	❌	✅
fly-out document data	✅	❌
context parameters	❌	❌
context data	✅	❌

Data dependencies

flowchart RL

dataView --> logView --> logViewId

displayParameters

subgraph unifiedSearchBar
  dataView
  queryString
  filters
  timeRange
  autoRefresh
end

histogramData --> dataView
histogramData --> queryString
histogramData --> filters
histogramData --> timeRange
histogramData --> autoRefresh

logEntries --> dataView
logEntries --> queryString
logEntries --> filters
logEntries --> timeRange
logEntries --> autoRefresh

highlightData --> highlightParameters

visibleLogEntries --> logEntries

flyOutData --> flyOutParameters
flyOutData --> dataView

Loading

State machines

The page has a state machine that is composed of several specialized state machines. The states are connected to the rendered React components via thin container components at the top level of the hierarchy.

Log stream page state machine

stateDiagram-v2

state logsStreamPageMachine {
  [*] --> waitingForLogView
  
  waitingForLogView --> logStream : logViewChanged
  
  state logStream {
    state "⚙ logEntries" as logEntries
    --
    state "⚙ histogram" as histogram
    --
    state "⚙ highlights" as highlights
    --
    state "⚙ flyOut" as flyOut
  }
}

Loading

stateDiagram-v2

state logView {
  [*] --> loadingLogView
  
  loadingLogView --> noLogView : failure
  loadingLogView --> resolvingLogView : success
  
  resolvingLogView --> noResolvedLogView : failure
  resolvingLogView --> resolvedLogView : success
}

Loading

Effects

• load log view
• load data view
• load histogram data
• load log entries
  • around
  • before
  • after
• load highlight data
• load fly-out data

URL state

We will use Kibana's KbnUrlStateStorage for handling URL state storage.

Page state <> URL state coordination

We will sync state via the syncState utility. Since we will not be using Kibana's State Containers we can use the following guidance to sync our KbnUrlStateStorage instance to our Redux store. This really just boils down to adhering to a get, set, and $state contract.

State structure

TODO: this will contain proposed state structure, actions etc

[elasticmachine]

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

[miltonhultgren]

we will not be using Kibana's State Containers

Is there a context for this decision?

Also, what happened to the state machine based ideas? Does Redux Toolkit allow us to use something similar?

[weltenwort]

This is obviously not set in stone, but the main arguments for using redux-toolkit are that it's already a dependency of Kibana and that the Lens and Discover teams are using it (or planning to) in their apps. Since the vision is to converge the apps and share as much code as possible we think aligning the "tech stack" as much as possible would be beneficial. In addition, some of the feedback we got was "it's cool, but has too steep of a learning curve for us".

Conceptually, our app state should still be a state machine, even if backed by redux-toolkit. Maybe we'll find a way to get the benefits of both. I can see several possible approaches:

• use redux as a service in a state machine
• use x-state as a middleware in redux
• come up with conventions and a middleware to bring state machine concepts to redux

I'd be happy to discuss and evaluate the options as we refine this issue.

[weltenwort]

ℹ️ We collected the investigation results in the description and will create follow-up implementation issues:

• [Logs UI] Refactor log stream page state #145131
• [Logs UI] Refactor log stream page query state #145133
• [Logs UI] Refactor log stream page time state #145137
• [Logs UI] Add log stream page filter state and UI #142764