Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discuss] Global / Shared state plugin #58721

Closed
Dosant opened this issue Feb 27, 2020 · 2 comments
Closed

[Discuss] Global / Shared state plugin #58721

Dosant opened this issue Feb 27, 2020 · 2 comments
Labels
discuss Feature:StateManagement impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:small Small Level of Effort triage_needed

Comments

@Dosant
Copy link
Contributor

Dosant commented Feb 27, 2020

In NP there is no concept of GlobalState. Plugins have their internal state which is preserved during navigation within different apps. #39855

Without doubting benefits of this approach, there are also some rare use cases, where an abstraction similar to GlobalState would be helpful.

For example: rendering url to a different place inside Kibana.
Whenever such URL is rendered, apps should not forget to pull from the plugins and serialise any important state into the URL.
Basically to render a link to a different place in kibana, app have to do something like this:

// dashboard is just an example
const link = getDashboardLink({
 filters: getFilters(),
 time: getTime(),
 refreshInterval: getRefreshInterval(),
...otherDashboardRelatedOptions
})

return <a href={link} />

The link should also be re-rendered whenever any of the dependencies change.

Another use case is syncing state with browser location.
Kibana apps sync data plugin's state into the url and we introduced useful observable to subscribe for changes to data plugin's state which merges states from different data plugin's services #57168 . Then apps wire it up to browser location syncing. @ppisljar pointed out problems with this approach: this helper is local to data plugin and it won't work anymore if we split data plugin's services into multiple separate plugins or if we have plugin's state to sync to url along with data plugin's state and app's state.

So maybe worth consider building a plugin for registering such global state pieces. And this plugin will provide apps with single observable for state pieces that need to be serialised into rendered urls (or synced to browser location). This will lift off the burden from apps to make all the orchestration of different states on their own.

The flow would look something like this:

  1. Have global state plugin - which is like registry of states we want to share between navigations within kibana
  2. This plugin has a state$ observable which exposes merged state object. it emits only when things actually change. It also can have changes prop which specifies what exactly has changes since last emit (coud be convenient for different optimisations on app level)
  3. To update the link:
const sharedState = useObservables(global.state$)
const link = getDashboardLink({
 ... sharedState,
...otherDashboardRelatedOptions
})
return <a href={link} />
  1. This probably could also be helpful for current sub-url-tracking solution. Since it uses data plugin's state$ observable. And this plugin would be a more generic replacement for data's specific use case.

  2. This probably is more generic replacement of - Implement data.query service observables to track state changes #57168

@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app-arch (Team:AppArch)

@exalate-issue-sync exalate-issue-sync bot added impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:small Small Level of Effort labels Jun 21, 2021
@ppisljar
Copy link
Member

ppisljar commented Aug 8, 2022

Thank you for contributing to this issue, however, we are closing this issue due to inactivity as part of a backlog grooming effort. If you believe this feature/bug should still be considered, please reopen with a comment.

@ppisljar ppisljar closed this as completed Aug 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss Feature:StateManagement impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:small Small Level of Effort triage_needed
Projects
None yet
Development

No branches or pull requests

3 participants