[State Management] - Remove GlobalState from dashboard#55158
[State Management] - Remove GlobalState from dashboard#55158Dosant merged 18 commits intoelastic:masterfrom
Conversation
d0bbbf5 to
51043ea
Compare
|
Pinging @elastic/kibana-app-arch (Team:AppArch) |
src/legacy/core_plugins/kibana/public/dashboard/np_ready/dashboard_app_controller.tsx
Outdated
Show resolved
Hide resolved
51043ea to
c567e32
Compare
b60cad0 to
79850bf
Compare
flash1293
left a comment
There was a problem hiding this comment.
It seems like the browser history isn't written correctly in all cases when filters get pinned.
To reproduce:
- Create filter pill
- Pin the filter
- Change something in the pilled filter (e.g. invert)
- Press back button (action gets undone correctly)
- Press back button again (I would expect the filter to become unpinned) -> nothing happens
- Press back button again -> filter disappears completely and I can't go forward anymore (history is lost)
src/legacy/core_plugins/kibana/public/dashboard/np_ready/lib/sync_app_filters.ts
Outdated
Show resolved
Hide resolved
lizozom
left a comment
There was a problem hiding this comment.
Overall looks good.
Added another minor comment.
src/legacy/core_plugins/kibana/public/dashboard/np_ready/application.ts
Outdated
Show resolved
Hide resolved
@flash1293, thanks for finding this bug! Indeed edge case when filter change mutates both app filters and global filters. (Pin -> add to global & remove from app). This should be fixed now |
flash1293
left a comment
There was a problem hiding this comment.
Tested and everything works fine for me, thanks for this! I left one comment suggesting light restructuring that would make the code safer and easier to get IMHO, but I don't consider it a blocker because I will continue working on that area of the code soon.
| const angularGlobalStateHacks: AngularGlobalStateHacks = {}; | ||
|
|
||
| export const renderApp = (element: HTMLElement, appBasePath: string, deps: RenderDeps) => { | ||
| const history = createHashHistory(); |
There was a problem hiding this comment.
nit: We could put that part into a function initGlobalStateHandling that is called in the dashboard controller in src/legacy/core_plugins/kibana/public/dashboard/np_ready/dashboard_app_controller.tsx and in the listing controller in src/legacy/core_plugins/kibana/public/dashboard/np_ready/legacy_app.js - initGlobalStateHandling would return a function that stops the syncing and can be registered within the controller using $scope.$on('$destroy', () => {. Then we don't need a reference on the application level and don't need to overwrite typescripts type checks
There was a problem hiding this comment.
thanks, looks better 👍
Hope I got it right.
3a51104
…agement/global-state-dashboard # Conflicts: # src/plugins/data/public/query/filter_manager/filter_manager.test.ts
…agement/global-state-dashboard
| const newObj = await this.props.container.addSavedObjectEmbeddable(type, id); | ||
|
|
||
| const finalPanels = this.props.container.getInput().panels; | ||
| const finalPanels = _.cloneDeep(this.props.container.getInput().panels); |
There was a problem hiding this comment.
What changed here, that made you clone the panels?
There was a problem hiding this comment.
State containers deeply freeze the object in dev mode, which allows to find places where we unintentionally mutate objects passed into services. The freezing pointed me to this replace_panel_flyout:
- Tweaked the code to not directly mutate original panels
- Fixed the call
container.updateInput(finalPanels)->container.updateInput({panels: finalPanels). Typescript didn't complain because updates
We discussed it with @streamich.
And in the end I decided that it would be easier to fix this piece of code in replace_panel_flyout then making sure that all places where data is passed from state container into embeddable container is cloneDeeped
| public static setFiltersStore( | ||
| filters: esFilters.Filter[], | ||
| store: esFilters.FilterStateStore, | ||
| shouldOverrideStore = false |
There was a problem hiding this comment.
Why did you have to add this?
There was a problem hiding this comment.
These make sense to me in case of setGlobalFilters and setAppFilters.
This what I was thinking:
- In both of those methods we need to handle the case, when filters with incorrect "$store" value are passed in
- We have couple options then:
- Just ignore such and do nothing
- Throw an error
- Override - I went with this one.
|
@elasticmachine merge upstream |
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
There was a problem hiding this comment.
Tested and seems to be working.
I think the external APIs for syncing can be improved, but for now, this is a good step forward.
However, I wouldn't implement this solution in other plugins before improving the interfaces in a follow up PR.
I'll create an issue to discuss this.
Removes GlobalState from dashboard app
Summary
Part of #44151
Removes GlobalState from dashboard app
depends on #54105Open for discussion: #55339 where to put and how to abstract syncing filters & time - https://github.com/elastic/kibana/pull/55158/files#diff-5e89f9f26cbd7f233495a2e97789a306R51
And how to make syncing of not "pinned" filters not an application concern - https://github.com/elastic/kibana/pull/55158/files#diff-47ad20cc6caa58a3e9c204106013514fR151
Checklist
Use
strikethroughsto remove checklist items you don't feel are applicable to this PR.For maintainers