Skip to content
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

Closed
wants to merge 70 commits into from

Conversation

ThomThomson
Copy link
Contributor

@ThomThomson ThomThomson commented Jun 29, 2020

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.

LensCreateByValue

This PR also allows for editing lens embeddables by value.

LensEditByValue

NEW: This PR also works with the Add to Library action, and the Unlink from Library action.

Aug-20-2020 16-13-20

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 to true:

allowByValueEmbeddables: schema.boolean({ defaultValue: false }),

This PR also makes use of the attribute service code found in #68719.

New Functionality & Tests to Cover

  • Creating a lens visualization via dashboard 'create new' button will now show the 'save and return' button. Save and return will add the lens visualization to the dashboard by value. 'save as' will prompt for a name, then add a 'by reference' panel to the dashboard.
  • Creating/editing a lens visualization through the visualize app will only show the original 'save' button.
  • Editing a lens embeddable by value should redirect to the edit_by_value endpoint. Save and return should properly apply edits back to the dashboard.
  • When editing a lens visualization by value running save as without add to dashboards on save should redirect the editor to /edit/{savedObjectId}
  • When editing a lens visualization by value running save as with add to dashboards on save should return to dashboard and replace the by value embeddable with a by reference embeddable. The embeddableId should be persisted.
  • Editing a lens embeddable by reference should work exactly as before.

Technical Diagram

Screen Shot 2020-06-29 at 6 40 59 PM

Checklist

Delete any items that are not applicable to this PR.

For maintainers

ThomThomson added a commit to ThomThomson/kibana that referenced this pull request Jul 8, 2020
@ThomThomson ThomThomson mentioned this pull request Jul 8, 2020
1 task
);
}
// If the incomingEmbeddable does not yet exist in the panels listing, create a new panel using the container's addEmbeddable method.
if (
Copy link
Contributor

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 😬

Copy link
Contributor Author

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<
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

@majagrubic majagrubic left a 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.

Copy link
Contributor

@flash1293 flash1293 left a 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.

x-pack/plugins/lens/public/app_plugin/app.test.tsx Outdated Show resolved Hide resolved
x-pack/plugins/lens/public/app_plugin/app.tsx Outdated Show resolved Hide resolved
x-pack/plugins/lens/public/app_plugin/app.tsx Outdated Show resolved Hide resolved
Copy link
Contributor

@wylieconlon wylieconlon left a 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:

  1. Create a new dashboard
  2. Create a Lens visualization for the non-default index pattern, and save it to the new dashboard
  3. The filters in the dashboard will show the wrong field names

With the flag enabled:

Steps to reproduce:

  1. Edit a dashboard with a Lens saved object, and click "Unlink from library"
  2. Edit the Lens visualization that you just unlinked
  3. Make a change and then click "Save and return"
  4. This error appears:

Screen Shot 2020-08-25 at 4 09 21 PM

Copy link
Contributor

@wylieconlon wylieconlon left a 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;
  ...
}

x-pack/plugins/lens/kibana.json Show resolved Hide resolved
export function getEditPath(id: string) {
return `#/edit/${encodeURIComponent(id)}`;
export function getEditPath(id: string | undefined) {
return id ? `#/edit/${encodeURIComponent(id)}` : `#/${LENS_EDIT_BY_VALUE}`;
Copy link
Contributor

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?

x-pack/plugins/lens/public/app_plugin/app.tsx Show resolved Hide resolved
type: this.type,
savedObjectId: (input as LensByReferenceInput)?.savedObjectId,
};
const expression = await this.deps.documentToExpression(this.savedVis);
Copy link
Contributor

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,
};
Copy link
Contributor

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?

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Build metrics

@kbn/optimizer bundle module count

id value diff baseline
visualize 310 -5 315

async chunks size

id value diff baseline
lens 30.5KB +4.6KB 25.9KB
maps 3.3MB +85.0B 3.3MB
visualize 690.6KB -3.2KB 693.8KB
total +1.5KB

page load bundle size

id value diff baseline
dashboard 704.1KB +1.9KB 702.2KB
embeddable 430.5KB -49.0B 430.5KB
lens 874.4KB +7.0KB 867.3KB
total +8.9KB

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@ThomThomson
Copy link
Contributor Author

ThomThomson commented Sep 23, 2020

Closed in favour of #77561

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Dashboard Dashboard related features Feature:Embedding Embedding content via iFrame Feature:Lens release_note:enhancement Team:Visualizations Visualization editors, elastic-charts and infrastructure v7.10.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants