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

[State Management] State syncing helpers for query service I #56128

Merged
merged 44 commits into from
Feb 27, 2020

Conversation

Dosant
Copy link
Contributor

@Dosant Dosant commented Jan 28, 2020

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:

interface QueryState {
  time?: TimeRange;
  refreshInterval?: RefreshInterval;
  filters?: Filter[];
}

interface QueryStateChange {
  time?: boolean; // time range has changed
  refreshInterval?: boolean; // refresh interval has changed
  filters?: boolean; // any filter has changed
  appFilters?: boolean; // specifies if app filters change
  globalFilters?: boolean; // specifies if global filters change
}

state$: Observable<{ changes: QueryStateChange; state: QueryState }>;

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

For maintainers

Dosant and others added 6 commits February 6, 2020 14:37
…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
@elastic elastic deleted a comment from kibanamachine Feb 6, 2020
@elasticmachine
Copy link
Contributor

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

…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
@Dosant Dosant changed the title [State Management][Discuss] Data plugin state management utils improvements [State Management] State syncing helpers for query service Feb 16, 2020
@Dosant Dosant changed the title [State Management] State syncing helpers for query service [State Management] State syncing helpers for query service I Feb 16, 2020
@lizozom
Copy link
Contributor

lizozom commented Feb 22, 2020

@elasticmachine merge upstream

@streamich streamich mentioned this pull request Feb 24, 2020
30 tasks
@lizozom
Copy link
Contributor

lizozom commented Feb 25, 2020

@elasticmachine merge upstream

Copy link
Contributor

@lizozom lizozom left a 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

@Dosant Dosant requested a review from ppisljar February 25, 2020 14:14
Copy link
Contributor

@flash1293 flash1293 left a 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(
Copy link
Contributor

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?

Copy link
Contributor Author

@Dosant Dosant Feb 26, 2020

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?

Copy link
Contributor

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 || []),
Copy link
Contributor

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

@Dosant
Copy link
Contributor Author

Dosant commented Feb 26, 2020

@elasticmachine merge upstream

@Dosant
Copy link
Contributor Author

Dosant commented Feb 27, 2020

@elasticmachine merge upstream

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@Dosant Dosant merged commit 2b4a9fd into elastic:master Feb 27, 2020
Dosant added a commit to Dosant/kibana that referenced this pull request Feb 27, 2020
…#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.
@Dosant
Copy link
Contributor Author

Dosant commented Feb 27, 2020

Planning to consider this as a more long term follow up: #58721

Dosant added a commit that referenced this pull request Feb 27, 2020
…#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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Filters Feature:StateManagement release_note:plugin_api_changes Contains a Plugin API changes section for the breaking plugin API changes section. v7.7.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants