* improve test stability
* query string input manager (needed for search demo)
* docs
* dashboard
* Fix jest
* mock fix
* Allow restoring a saved query
* sync url
* Luke's fix to test
* cleanup
* lens jest tests
* docs
* use queryStringManager.getDefaultQuery
Don't sync query to global state
* Update app.test.tsx
lens mock
* jest fix
* jest
* use new api in the example
* Rename state param to query to match url state
* Apply changes to discover
* Update src/plugins/data/public/query/query_string/index.ts
Co-authored-by: Anton Dosov <dosantappdev@gmail.com>
* Improve query string state manager
* Cleanup dashboard code
* Handle refresh button
* Set initial dashboard state
* visualize state
* remove unused
* docs
* fix example
* fix jest
* fix filter app state in discover
* fix maps test
* jest
Co-authored-by: Anton Dosov <anton.dosov@elastic.co>
Co-authored-by: Anton Dosov <dosantappdev@gmail.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
* Kibana developer examples
* Batch explorer tests should be run in examples config
* Fix tests
* add codeowner for new developer examples plugin & readme cleanup
* Try to frame embeddable wording based on what a developer's goals are.
* Add noopener noreferer, fix bad merge
* Remove bfetch.png
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
The needed change is to rely on history as source of truth for location instead of window.location.
btw, This makes possible to test state syncing utils integration using createMemoryHistory()
One issue was discovered after this change:
When switching from context to discover url was incorrect. history.location inside state syncing utils didn't get the last update. This happened, because history instance created in discover wasn't used in context app and when all listeners unsubscribed from it - it stopped receiving location updates. To fix this I just reused one history instance in discover, context and their kbnUrlTracker
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.
Some maintenance and minor fixes to state containers based on experience while working with them in #53582
Patch unit tests to use current "terminology" (e.g. "transition" vs "mutation")
Fix docs where "store" was used instead of "state container"
Allow to create state container without transition.
Fix freeze function to deeply freeze objects.
Restrict State to BaseState with extends object.
in set() function, make sure the flow goes through dispatch to make sure middleware see this update
Improve type inference for useTransition()
Improve type inference for createStateContainer().
Other issues noticed, but didn't fix in reasonable time:
Can't use addMiddleware without explicit type casting #54438
Transitions and Selectors allow any state, not bind to container's state #54439
Today, apps rely on AppState and GlobalState in the ui/state_management module to deal with internal (app) and shared (global) state. These classes give apps an ability to read/write state, when is then synced to the URL as well as sessionStorage. They also react to changes in the URL and automatically update state & emit events when changes occur.
This PR introduces new state synching utilities, which together with state containers src/plugins/kibana_utils/public/state_containers will be a replacement for AppState and GlobalState in New Platform.
