-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Dashboard] Add visualization by value to Dashboard #68902
Conversation
@elasticmachine merge upstream |
bece04b
to
cd6735d
Compare
Pinging @elastic/kibana-app (Team:KibanaApp) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cool! i think we should throw some things around but its very close.
@@ -342,6 +359,32 @@ export class DashboardPlugin | |||
} | |||
} | |||
|
|||
private navigateToDashboard(core: CoreStart, dashInput: EmbeddableInput) { | |||
if (!this.getActiveUrl) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we navigate to empty dashboard if one was not loaded ? should we allow for passing dashboardId to navigateToDashboard function ?
@@ -133,14 +134,21 @@ export class VisualizeEmbeddableFactory | |||
} | |||
} | |||
|
|||
public async create() { | |||
public async create(input: VisualizeInput & { hideVisModal: boolean }, parent?: IContainer) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could we rather say that input can also be undefined, and if its undefined we show the modal else we create from the input
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
input won't be undefined in case of a "regular save", it contains timeRange and query and a few other parameters:
export interface VisualizeInput extends EmbeddableInput { |
src/plugins/visualizations/public/embeddable/visualize_embeddable_factory.tsx
Outdated
Show resolved
Hide resolved
@@ -253,6 +253,35 @@ function VisualizeAppController($scope, $route, $injector, $timeout, kbnUrlState | |||
}); | |||
}; | |||
|
|||
const createVisReference = () => { | |||
const currentDashboardInput = dashboard.getLastLoadedDashboardAppDashboardInput(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think we should not be loading the dashboard and manipulating it in visualize (this requires internal knowledge about dashboard structure)
rather we should navigate to dashboard and let dashboard take care of that:
navigateToApp('dashboard', { newVis: vis.serialize(); })
and then dashboard should check for newVis
on its state, if its there it can append it to its panels
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. The problem here is that we started working on a better inter-app communication logic and the PR hasn't been merged yet. As I mentioned in the description, this code is definitely going to change after #67064 is merged, and what you're describing is pretty similar to how it is going to work. We'll navigate to dashboard and pass the serialized vis as input, and the dashboard is going to render.
I did not want to base this PR off an unmerged PR, but I also didn't want to be blocked by that change.
I think this way of communicating between dashboard and visualization is good enough for now.
12addcd
to
0bb50b9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
code LGTM, looking forward to improved communication between visualize and dashboard as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code LGTM. I was more thorough on the vis editor code. Tested it on Chrome and it works as expected.
💔 Build Failed
Failed CI StepsBuild metrics@kbn/optimizer bundle module count
History
To update your PR or re-run it, just comment with: |
Thanks @ppisljar , @stratoula and @ThomThomson for your reviews. I'm closing this PR in favor of: #69898 and will ping you for another review there 😃 |
Summary
This is the first pass in adding Visualization to Dashboard by value. It should be fully functional. However, this solution is based on passing dashboard input to visualize editor, and then using this input to pass visualization data back to dashboard, which is a bit hacky (and won't work in case of a page reload). I will change this logic after #67064 is merged.
I'm hiding the new flow behind a "feature flag" by utilizing the server-side config. The current flow should remain unaffected. In order to test this locally, the value of the
showNewVisualizeFlow
flag needs to be set to "true" insrc/plugins/visualize/config.ts
andsrc/plugins/visualize/server/index.ts
.Checklist
Delete any items that are not applicable to this PR.
- [] Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support- [ ] Documentation was added for features that require explanation or tutorialsFor maintainers