-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[State Management] State syncing helpers for query service I #56128
[State Management] State syncing helpers for query service I #56128
Conversation
…t-with-state-setup # Conflicts: # src/plugins/data/public/query/state_sync/index.ts # src/plugins/data/public/query/state_sync/sync_global_state_with_url.test.ts # src/plugins/data/public/query/state_sync/sync_query.ts # src/plugins/data/public/ui/search_bar/create_search_bar.tsx # src/plugins/data/public/ui/search_bar/search_bar.tsx
timefilter initial state
…ozom/kibana into dev/experiment-with-state-setup
…ozom/kibana into dev/experiment-with-state-setup
Pinging @elastic/kibana-app-arch (Team:AppArch) |
…ibana into dev/experiment-with-state-setup
…t-with-state-setup # Conflicts: # src/legacy/core_plugins/kibana/public/dashboard/np_ready/legacy_app.js # src/legacy/core_plugins/kibana/public/dashboard/plugin.ts # src/plugins/data/public/query/state_sync/connect_to_app_state.test.ts # src/plugins/data/public/query/state_sync/sync_app_filters.ts # src/plugins/data/public/query/state_sync/sync_query.ts # src/plugins/data/public/ui/search_bar/search_bar.tsx
…t-with-state-setup
@elasticmachine merge upstream |
@elasticmachine merge upstream |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a great step forward in the right direction.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested and still works as expected - left some nits but nothing required and can also be addressed later.
@@ -96,12 +94,19 @@ export class VisualizePlugin implements Plugin { | |||
stateParams: [ | |||
{ | |||
kbnUrlKey: '_g', | |||
stateUpdate$: querySyncStateContainer.state$, | |||
stateUpdate$: data.query.state$.pipe( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like this is a common way of using state$
- what about moving into into data
(either as a helper or as a second globalState$
observable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initially this pr had app$
global$
observables but we decided to go for more generic approach.
but I also don't like this duplications across kibana apps.
Maybe there is a place, where I could put this operator
, which would be common for kibana apps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there is no good place for this helper, let's leave it as is. IMHO a little bit of redundancy is preferable over abstractions in the wrong places.
const stopSyncingAppFilters = connectToQueryState( | ||
queryService, | ||
{ | ||
set: ({ filters }) => dashboardStateManager.setFilters(filters || []), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like we can just pass the actual state container used by dashboardStateManager
down here instead of emulating it like this and it would do the same thing - not required though
examples/state_containers_examples/public/with_data_services/components/app.tsx
Show resolved
Hide resolved
@elasticmachine merge upstream |
@elasticmachine merge upstream |
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
…#56128) Before this pr: Discover, Visualise and Dashboard in setup phase create own state containers which watch for pinned filters, time and refresh interval changes. This watching and state comparisons happen for each plugin separately and not only when a specific app is mounted. So we ended up with a bunch of similar synchronous work which happens every time query services state changes. After this pr: Query service exposes observable to watch for changes (state$). Discover, Visualise and Dashboard use this observable for sub url tracking instead of creating its own.
Planning to consider this as a more long term follow up: #58721 |
…#58711) Before this pr: Discover, Visualise and Dashboard in setup phase create own state containers which watch for pinned filters, time and refresh interval changes. This watching and state comparisons happen for each plugin separately and not only when a specific app is mounted. So we ended up with a bunch of similar synchronous work which happens every time query services state changes. After this pr: Query service exposes observable to watch for changes (state$). Discover, Visualise and Dashboard use this observable for sub url tracking instead of creating its own.
Summary
The main reason for this changes is new sub url tracking implemented in #57307 and #55818. It improves performance of new implementation.
Before this pr:
Discover, Visualise and Dashboard in setup phase create own state containers which watch for pinned filters, time and refresh interval changes. This watching and state comparisons happen for each plugin separately and not only when a specific app is mounted. So we ended up with a bunch of similar synchronous work which happens every time query services state changes.
After this pr:
Query service exposes observable to watch for changes (
state$
). Discover, Visualise and Dashboard use this observable for sub url tracking instead of creating its own.Dev Docs
Query service of data plugin now has state$ observable which allows to watch for query service data changes:
Checklist
Use
strikethroughsto remove checklist items you don't feel are applicable to this PR.For maintainers