[Portable Dashboards] Prepare Redux Embeddable System for Dashboard

[ThomThomson]

Part of #133677

Redux Embeddables System

In the Controls project, a new system was added to allow Embeddables to easily use redux toolkit to better manage their state. This creates an easily understandable communication layer between the Embeddable class and the inner react components via the redux store and a context.

This system is quite robust and is used for all of the control embeddables. That said it has a few drawbacks which can be easily addressed before using it for state management of the Dashboard Container.

What needs to change?

Single Redux Store

The original redux embeddable system uses a single redux store with reducers being dynamically added and removed on embeddable creation / deletion. This works well, but the selector is used to narrow down the embeddable by ID to fetch only appropriate state which means the selector cannot be used for its intended purpose, narrowing down state changes which require a re-render.

This should be fixed by changing the wrapper to create a new store for each embeddable it is used with, and destroy the store when the embeddable is destroyed. This will allow the selector to be used correctly.

Only for input

The original redux embeddable system was only used to track embeddable input, which meant that anything which was placed in the redux store was also persisted into the saved object. This necessitated another system for interaction between the embeddable and the react components because not all state should be persisted.

This should be fixed by making the redux store universal for any type of state that an embeddable could need. These three levels of state are as follows:

1. Embeddable Input is all state which should be persisted to re-create the embeddable as it is.
2. Embeddable Output is all state which is created by an embeddable to communicate with outside code.
3. Embeddable State is ephemeral state which needs to be tracked, but should be lost on page changes.

Only for use with React Components

The original redux embeddable system was created as a react wrapper which was in charge of creating the store, injecting the reducers, and tracking all state for the components underneath. This allowed for communication between the embeddable class and the react components underneath. In the embeddable class, state would be updated via the embeddable's updateInput method, which is the same way external code would update it. Inside the Embeddable's react component, state changes would be dispatched via redux.

The system picked up all changes in both types of state and kept them in sync. This works great from a user point of view.

The problem with this is: From a DX point of view, embeddable state should be managed in the same way regardless of where it is changed from.

To fix this, the redux embeddable system should be changed so that it can be created by an initial method, and synced by a react component / wrapper. This way, the embeddable class can also use the dispatch methods and the reducers to influence its own state.

Other Considerations

Because this Redux Embeddable system underpins the Controls project as well, some light structural changes should be expected there as well. These changes will involve removing some extraneous state sync systems, and aligning all of the controls state with the new version of the Redux Embeddables system.

[elasticmachine]

Pinging @elastic/kibana-presentation (Team:Presentation)

[ThomThomson]

Proposed Architecture: