[State Management] State syncing helpers for query service I#56128
[State Management] State syncing helpers for query service I#56128Dosant merged 44 commits intoelastic:masterfrom
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
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
flash1293
left a comment
There was a problem hiding this comment.
Tested and still works as expected - left some nits but nothing required and can also be addressed later.
| { | ||
| kbnUrlKey: '_g', | ||
| stateUpdate$: querySyncStateContainer.state$, | ||
| stateUpdate$: data.query.state$.pipe( |
There was a problem hiding this comment.
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.
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.
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.
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