search

elastic / kibana

Your window into the Elastic Stack
https://www.elastic.co/products/kibana
Other
19.7k stars 8.12k forks source link

[Discussion] State management tools in Kibana #101253

Closed Bamieh closed 7 months ago

Bamieh commented 3 years ago

Summary

Discussion issue around using state management tools in Kibana

Concerns

A redux-like state management tool becomes a necessity as complexity increases, especially in react.

Currently we have multiple state management libraries across kibana:

Then we have the helper tools for these libraries such as:

Repercussions

Some of these state management libraries and helpers come with considerable size and performance cost. Having some guidelines makes it easier for teams to make decisions around how to manage their application state and makes it less confusing to develop plugins.

End goals

  1. Contributing to different plugins with different state management tools makes it confusing and increase the number of things devs need to learn to work effectively.
  2. Easier for teams to decide and transition into using state management tools.
  3. Avoid increasing the kibana bundle size and number of dependenciess we have to maintain.
  4. State management in react is an important concept, it is good to have best practices around using it in Kibana.

Potential solutions

  1. Kibana wide guidelines -part of best practices in docs- around how teams should approach state management in their application including;

    • How to manage state in react for a simple plugin
    • What modules / heleprs to use when transitioning from react native state management tools (context and useState) into redux-like modules.
    • When to use our own stateContainers module provided by kibana_utils.

  2. A meta issue to contain the number of state management libraries and helpers we are using or get rid of some of them (related: https://github.com/elastic/kibana/issues/88678)

elasticmachine commented 3 years ago

Pinging @elastic/kibana-core (Team:Core)

elasticmachine commented 3 years ago

Pinging @elastic/kibana-app (Team:KibanaApp)

elasticmachine commented 3 years ago

Pinging @elastic/kibana-presentation (Team:Presentation)

flash1293 commented 3 years ago

@clintandrewhall @ThomThomson Interested in your thoughts here

mbondyra commented 3 years ago

I agree with unifying the solutions for state management for Kibana for readability, maintenance and performance. However, let's keep in mind that some of the tools mentioned in this issue are not duplicate of each other, but they complement each other - for example, redux-toolkit uses redux, redux-react, immer and reselect and in that sense these are not alternatives for using redux-toolkit (maybe except for pure redux).

yakhinvadim commented 3 years ago

To add to the list: Enterprise Search solution is moving from a standalone UI to being a part of Kibana. The only unique dependency that we brought to Kibana was a state management library Kea - wrapper around redux.

sorenlouv commented 3 years ago

Thanks for starting this. Cutting down on the number of libraries we have in Kibana is always good.

A redux-like state management tool becomes a necessity as complexity increases, especially in react.

I'm probably in the minority here but I think Redux is overkill for most (web)applications and useState with context (and hooks for consuming) is a very simple approach that scales reasonably well.

The advantage I see of using something dead simple (albeit less powerful) is that there are not terribly many ways to customize it, making it easier for consumers to use regardless what part of the codebase they are in. Redux OTOH comes with many different conventions depending on who you ask.

Imo we should not go for the most powerful solution that can handle every use case but instead the simplest solution that can handle 90% of use cases.

Ps i initially built APM with Redux 😊

flash1293 commented 3 years ago

I'm probably in the minority here but I think Redux is overkill for most (web)applications and useState with context (and hooks for consuming) is a very simple approach that scales reasonably well.

I can definitely see that and that's what made us start Lens in exactly this way, but in the current state we run into all sorts of issues because of it (especially around handling side effects and integrating with other parts of Kibana).

Redux OTOH comes with an infinite number of different conventions depending on who you ask.

Yes, this is an issue. redux-toolkit is nice in this regard because it gives an answer to these questions and is (hopefully) good enough so we can just stick with it without having discussions about different flavors/conventions.

sorenlouv commented 3 years ago

redux-toolkit is nice in this regard because it gives an answer to these questions and is (hopefully) good enough so we can just stick with it without having discussions about different flavors/conventions.

If we go the redux route redux-toolkit sounds like a great approach 👍

lukeelmers commented 3 years ago

When to use our own stateContainers module provided by kibana_utils.

cc @elastic/kibana-app-services as they maintain the state container module, which is redux-like: https://github.com/elastic/kibana/blob/master/src/plugins/kibana_utils/docs/state_containers/README.md

I believe the original intent of this module was to solve this exact problem, while also providing integration with other shared services & utilities (like the state sync utils), but I'm not sure if there are any plans to start using it in more places ATM.

Dosant commented 3 years ago

cc @elastic/kibana-app-services as they maintain the state container module, which is redux-like: https://github.com/elastic/kibana/blob/master/src/plugins/kibana_utils/docs/state_containers/README.md I believe the original intent of this module was to solve this exact problem, while also providing integration with other shared services & utilities (like the state sync utils), but I'm not sure if there are any plans to start using it in more places ATM.

I believe that state_containers and URL sync utils did well as migrations step from legacy global angular app_state.js / global_state.js. And to be clear, IMO, these are not in the state to be promoted as a recommended way to manage state for the whole app in Kibana.

Today they are used:

@sqren: If we go the redux route redux-toolkit sounds like a great approach

I like the idea of recommending and aligning on redux-toolkit as a recommended tool for redux-like app state management.

Like:

In case your app needs redux, then recommended tool is redux-toolkit

But I'd also clearly state that it is OK:

sorenlouv commented 3 years ago

But I'd also clearly state that it is OK:

  • to use just state/context for simpler apps.
  • Sometimes I also find myself wanting to use react-query (e.g. management page with a list of entities with auto-refresh: like search-sessions/reporting).
  • I'd also not take recoil/zustand/etc.. out of the picture in case one of our highly interactive editors hits performance issues with redux (support for transient updates).

++

jloleysens commented 3 years ago

++

I ++ this ++ 😄

Many of the ES UI plugins were migrated away from react-redux because in practice it was a more sophisticated tool than necessary. They still use the redux pattern, but implement it using multiple Contexts (as slices) and memo'd components for taming rendering cycles. I think this offers a light-weight tool for apps of medium complexity. CC @sebelga

sebelga commented 3 years ago

I also ++ JL's ++ so that makes 6 in total 😄

As our general rule is to tend to keep the state closer to the component it's been a long time we've needed a "state management" tool in the stack management team (sorry if it rhymes!).

We also have yet another state management tool for most of our apps: the form lib. That lib + react context is all we need.

mattkime commented 1 year ago

I'd like to restart this conversation. Its an important topic. Kibana has a considerable amount of tech debt around state management and it would be best if each team or individual didn't need to start from scratch to solve their stateful problems.

First, I think we need to make sure we have a well defined problem statement that properly encapsulates different state management challenges. In my experience, react state management hooks work well for simple cases but simply don't scale - if there's enough complexity, react hooks will become slow and difficult to use and it can be hard to create the desired outcome. Async state changes can be an added challenge - loading data or even a series of such requests. Simple should be simple and difficult should be possible.

Second, I'd like to ground decision making in example code. If we're going to say that one way of working is better than another we should be able to do a side by side comparison. Its common for two different ways of working to be roughly equivalent which we should also acknowledge.

Finally, we're working toward a recommendation rather than something binding. No code will 'have to' be refactored because of this and engineers are still free to choose their own tools. However, we can provide a helpful starting point and straight forward reasoning behind it.

I'm getting some eyes on some code I've written that uses observables to manage state. I'll share it shortly. Overall I'm very satisfied with the technique as it seems like a nice balance of solving the specific problem you're working on without too much indirection. I'll find out if others agree.

....and yes, this is basically a restatement of my last two space time projects.

ThomThomson commented 1 year ago

@mattkime is this discussion still ongoing? Are there any action items - or do you think we should close this issue for the time being, and try to build consensus on state management through smaller teams only instead of trying to standardize over the whole of Kibana?

stratoula commented 7 months ago

I am closing this as I don't see any action items