-
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
[Dashboard First] Lens By Value #70272
Conversation
55b68a0
to
a34d585
Compare
src/plugins/dashboard/public/application/embeddable/dashboard_container.tsx
Outdated
Show resolved
Hide resolved
…o avoid confusion. Added cancel button
e94152d
to
f497244
Compare
); | ||
} | ||
// If the incomingEmbeddable does not yet exist in the panels listing, create a new panel using the container's addEmbeddable method. | ||
if ( |
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 already started making this change in implementing attribute service for visualize, so again - the question is who goes first with this 😬
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 was hoping to sneak this one in before you started work on using attribute service. Seems like I was too slow on the draw!
|
||
import { EmbeddableInput, SavedObjectEmbeddableInput } from '..'; | ||
|
||
export interface ReferenceOrValueEmbeddable< |
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.
why is this showing as a diff? how is this not in master already?
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.
Oh, good catch. Merge issue meant that this was in the wrong place. I've deleted this file.
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.
Tested this in Chrome on Mac OS X. The embeddable - related code looks good to me. I'm not very familiar with the Lens code so would wait for an approval of someone from the Lens team.
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 focused on the Lens part here and most of the changes make sense to me. I left some small comments.
In terms of behavior, I noticed a custom panel title or time range is overwritten when editing a "by value" lens - seems like there is too much overwritten at some point.
The failing functional test seems like a real problem as well.
In general, it would be cool to have functional tests for the by value flows as well, but those can be added later as well once this moves out of the feature flag.
…for lens menu items
…into feature/lensByValue
…ming input to preserve custom panel titles
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 haven't reviewed the code fully, but I found bugs in the behavior.
Without the flag enabled:
Steps to reproduce:
- Create a new dashboard
- Create a Lens visualization for the non-default index pattern, and save it to the new dashboard
- The filters in the dashboard will show the wrong field names
With the flag enabled:
Steps to reproduce:
- Edit a dashboard with a Lens saved object, and click "Unlink from library"
- Edit the Lens visualization that you just unlinked
- Make a change and then click "Save and return"
- This error appears:
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.
My highest-level comment about the code is that it's too much complexity spread across a high number of places, and it looks like the extra complexity is not adequately tested because it can't be. A lot of this is due to decisions we made for a lower-complexity app, and are only breaking now.
Since the main change that you've made here is to introduce a new "mode" that affects the way that Lens saving, loading, and state management works, I think the solution lies in also creating a "mode" for the saved objects. Both modes would have the same interface and would be called in a predictable way.
For example, I'm imagining this kind of interface:
interface AppState {
mode: 'document' | 'value';
}
interface LensEditingMode {
load: () => Document;
save: () => Document;
...
}
export function getEditPath(id: string) { | ||
return `#/edit/${encodeURIComponent(id)}`; | ||
export function getEditPath(id: string | undefined) { | ||
return id ? `#/edit/${encodeURIComponent(id)}` : `#/${LENS_EDIT_BY_VALUE}`; |
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.
Was there a test for this? Should there be now?
type: this.type, | ||
savedObjectId: (input as LensByReferenceInput)?.savedObjectId, | ||
}; | ||
const expression = await this.deps.documentToExpression(this.savedVis); |
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.
Maybe you can simplify the whole thing by changing the signature of documentToExpression
?
@@ -144,9 +167,7 @@ export class Embeddable extends AbstractEmbeddable<LensEmbeddableInput, LensEmbe | |||
filters: cleanedFilters, | |||
}; |
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.
This is important to set on the first render, it seems like it isn't?
x-pack/plugins/lens/public/editor_frame_service/embeddable/embeddable.tsx
Show resolved
Hide resolved
x-pack/plugins/lens/public/editor_frame_service/embeddable/embeddable_factory.ts
Show resolved
Hide resolved
x-pack/plugins/lens/public/editor_frame_service/embeddable/embeddable_factory.ts
Show resolved
Hide resolved
💚 Build SucceededBuild metrics@kbn/optimizer bundle module count
async chunks size
page load bundle size
History
To update your PR or re-run it, just comment with: |
Closed in favour of #77561 |
Summary
This PR allows for Lens embeddables to be created and edited from a dashboard 'by value'. In concert with #72256, a faster work flow for dashboards is created, and the number of savedObjects can be greatly reduced.
This PR also allows for editing lens embeddables by value.
NEW: This PR also works with the Add to Library action, and the Unlink from Library action.
How to test this?
This is just one part of a much larger change, so all changes in this PR are hidden behind a configuration value. In order for the 'by value' workflow to be made default, some architectural changes need to be completed including #67931, #71499, and #61663
In order to test the new behaviour you'll need to set the
allowByValueEmbeddables
config value totrue
:kibana/src/plugins/dashboard/config.ts
Line 23 in 5b64a4c
This PR also makes use of the attribute service code found in #68719.
New Functionality & Tests to Cover
edit_by_value
endpoint. Save and return should properly apply edits back to the dashboard.save as
withoutadd to dashboards on save
should redirect the editor to/edit/{savedObjectId}
save as
withadd to dashboards on save
should return to dashboard and replace the by value embeddable with a by reference embeddable. The embeddableId should be persisted.Technical Diagram
Checklist
Delete any items that are not applicable to this PR.
For maintainers