mirror of
https://github.com/elastic/kibana.git
synced 2025-04-20 16:03:20 -04:00
5c4eae1286
Closes https://github.com/elastic/kibana/issues/174959 ## Summary This PR converts the Saved Search embeddable to the new React embeddable framework. There should not be **any** changes in user-facing behaviour (except for the intentional change described [here](https://github.com/elastic/kibana/pull/180536#discussion_r1647924825)) - therefore, testing of this PR should be focused on ensuring that no behaviour is changed and/or broken with this refactor. > [!WARNING] > The saved search embeddable takes **many forms** and so, while I tried my best to test everything thoroughly, it is very, very likely that I missed some test cases due to not being the expert in this area. It is important that @elastic/kibana-data-discovery in particular approaches this PR review with a fine-tooth comb 🙇 Thanks so much. ### Notes about the embeddable state: As part of this refactor, I made three significant changes to how the state is managed: 1. Once the embeddable is being built in `buildEmbeddable`, the **only difference** between the runtime state of a by reference and a by value panel is that the by reference one will have three saved object-specific keys: `savedObjectId`, `savedObjectDescription`, and `savedObjectTitle`. 2. Number 1 made it possible for me to "flatten out" the runtime state of the embeddable by removing the `attributes` key, which makes it easier to access the pieces of state that you need. 3. Previously, the `savedSearch` element of the Saved Search embeddable object was never modified; instead, changes made to the columns, sort, sample size, etc. from the dashboard were stored in `explicitInput`. This essentially created two sources of truth. With the new embeddable system, we only ever want **one** source of truth - so, the saved search is now modified **directly** when making changes from the dashboard. However, in order to keep behaviour consistent with the old embeddable, changes made from the dashboard to a by reference saved search **should not** modify the underlying saved object (this behaviour will have to change if we ever want inline editing for saved searches, but that is another discussion) - therefore, when **serializing** the runtime state (which happens when the dashboard is saved), we [only serialize state that has **changed** from the initial state](https://github.com/elastic/kibana/pull/180536/files#diff-7346937694685b85c017fb608c6582afb3aded0912bfb42fffa4b32a6d27fdbbR93-R117); then, on deserialization, we take this "changed" state and [**overwrite** the state of the saved search with it](https://github.com/elastic/kibana/pull/180536/files#diff-7346937694685b85c017fb608c6582afb3aded0912bfb42fffa4b32a6d27fdbbR44-R54). Note that this **only** applies to by reference saved searches - with by value saved searches, we don't have to worry about this and can freely modify the state. I also had to make changes to how the **search source** is stored in runtime state. Previously, when initializing the embeddable, fetching the saved search saved object also created and returned an **unserializable** search source object. However, in the new system, runtime state **most always be serializable** (see https://github.com/elastic/kibana/pull/186052) - therefore, I've had to instead use the **serialized** search source in my runtime state saved search - therefore, I've had to make changes to `toSavedSearch` method to [allow for a **serializable** saved search to be returned](https://github.com/elastic/kibana/pull/180536/files#diff-3baaeaeef5893a5a4db6379a1ed888406a8584cb9d0c7440f273040e4aa28166R160-R169). | | Runtime state (`input`) before | Runtime state after | |--------|--------|--------| | **By value** | ![image]( |
||
|---|---|---|
| .. | ||
| common | ||
| export_types | ||
| get_csv_panel_actions | ||
| mocks_server | ||
| public | ||
| server | ||