feat: define explore dashboards inline in metrics views via the explore: block#9680
feat: define explore dashboards inline in metrics views via the explore: block#9680nishantmonu51 wants to merge 3 commits into
explore: block#9680Conversation
…plore" and "Go to canvas dashboard"
nishantmonu51
added
Type:Feature
# Conflicts: # web-common/src/features/workspaces/VisualExploreEditing.svelte
| DEFAULT_PREVIEW_TABLE_HEIGHT, | ||
| } from "../config"; | ||
|
|
||
| export type WorkspaceView = "code" | "split" | "viz" | "explore"; |
There was a problem hiding this comment.
explore is only for metrics view so adding it to WorkspaceLayoutStore feels incorrect.
Maybe there is a way to make it a generic and take additional view params?
| href={getFileHref(exploreFilePath)} | ||
| onclick={() => { | ||
| if (definedInMetricsView) { | ||
| workspaces.get(exploreFilePath).view.set("explore"); |
There was a problem hiding this comment.
Storing the view is responsibility of editor and not this component. Perhaps a query param that gets parsed, stored as view and cleared is a better approach. We could do it (workspace)/files/[...file]/+page.ts, including routing to view based on definedInMetricsView
| ?.filter( | ||
| (res) => | ||
| res.meta?.name?.kind === ResourceKind.Component && | ||
| res.component?.state?.validSpec?.rendererProperties |
There was a problem hiding this comment.
This is just one way to get metrics view. There are other ways that runtime.ResolveCanvas in backend handles. So we would have to call ResolveCanvas on every canvas to get this reverse map.
| } | ||
|
|
||
| // Resolve the dimensions and measures selectors; when omitted, they default to all fields. | ||
| var dimensionsSelector *runtimev1.FieldSelector |
There was a problem hiding this comment.
Since we use the same UI for editing inline and explicit explores we should find a way to keep the parser code in sync. Maybe we can move explore definition specific fields to a new struct and move parsing there?
| // Create the Explore file, and navigate to it | ||
| await createAndPreviewExplore(client, queryClient, instanceId, resource); | ||
| // The generated metrics view defines its explore inline; open it | ||
| await previewInlineExplore(queryClient, newMetricsViewFilePath); |
There was a problem hiding this comment.
While this PR changes the backend it can be changed back anytime. So we should check the yaml generated and route based on that.
Same with other cases where we dont provide the yaml in param. Especially the case with AI generated ones where it is not deterministic.
| instanceId, | ||
| resource, | ||
| )} | ||
| onclick={() => enableInlineExploreAndPreview(queryClient, filePath)} |
There was a problem hiding this comment.
This option is now a bit misleading since we are not generating anything anymore. Also is incorrect for non-version1 metrics views.
2 participants
Makes the inline
explore:block the primary way to get an explore dashboard for aversion: 1metrics view, and builds the editing experience around it:explore:block now supportsdimensions:andmeasures:field selectors (defaulting to all), and the emitted explore is flagged withdefined_in_metrics_view.explore:block of the same file next to a live dashboard preview.create-and-preview-explore.tsis replaced byinline-explore.ts); generated metrics views (both AI and simple paths) include theexplore:block out of the box.Checklist: