-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Embeddables] Communicate Data View Ids #137493
Comments
Pinging @elastic/kibana-presentation (Team:Presentation) |
Pinging @elastic/kibana-app-services (Team:AppServicesSv) |
In general we have this architecture, where embeddable reports their state through the embeddable "output". (I'm not saying I'm a big fan of it.) But we have it, and it seems that embeddable "output" can be used here to subscribe to all embeddable data view changes; the whole data view does not need to be extracted - the output observable can be mapped to just data view ID, and further observable Something like: const dataViewId$ = embeddable.output$.pipe(
map(dataView => dataView.id),
distinctUntilChanged(),
); |
@vadimkibana this is the current implementation. |
This will be resolved by the Embeddables Rebuild project. |
How it works now
Dashboard needs to know which data views its child embeddables use in order to provide appropriate options when creating a filter or a control. Currently, most embeddables communicate their data views via their output. Dashboard reads the output, casts it and tries to grab the data view object from it.
Problems with this approach:
What should we do instead?:
Instead, it would be a better pattern to create a new interface something like
ICommunicatesDataViews
, which comes with a method to access aSubject<string>
called$onDataViewChange
that the embeddable can publish to when the data view changes.Notice this subject is of type string because it should only publish the data view Id, because the data views in use should already be cached in the data views service. We can access them this way rather than passing the full class instance around.
Another good change would be to make the top nav bar / the unified search bar take an array of dataViewIds, rather than an array of pre-fetched Data View objects.
More advanced fix
A more complex fix would be to add a system that lets embeddable parents easily subscribe to changes in certain states of their children.
CC @dokmic @flash1293, any feedback or other options is welcome!
The text was updated successfully, but these errors were encountered: