Skip to content

[BREAKINGCHANGE] remove dashbaord resource dependecy#97

Open
shahrokni wants to merge 1 commit intomainfrom
refactor/remove_dashbaord_Resource_core
Open

[BREAKINGCHANGE] remove dashbaord resource dependecy#97
shahrokni wants to merge 1 commit intomainfrom
refactor/remove_dashbaord_Resource_core

Conversation

@shahrokni
Copy link
Copy Markdown
Contributor

@shahrokni shahrokni commented Apr 2, 2026

Description

There is an ongoing effort to remove the core the dependency and replace them with what we have in the Spec.
This PR removes some of the dependencies (mostly DashboardResource, EphemeralDashboardResource) which have been already mentioned by @Nexucis

How does it replace the dependencies?

The PR introduces a new interface which represents an internal definition of any-Dashboard-Resource named DashboardMinimalResource.

  • DashboardResource, EphemeralDashboardResource from EditDatasourcesButton.tsx
  • DashboardResource, EphemeralDashboardResource from serializeDashboard.ts
  • DashboardResource, EphemeralDashboardResource from LeaveDialog.tsx
  • DashboardResource, EphemeralDashboardResource from common.ts
  • DashboardResource, EphemeralDashboardResource from dashboard-provider-api.ts
  • DashboardResource, EphemeralDashboardResource from DatasourceStoreProvider.tsx
  • DashboardResource, EphemeralDashboardResource from useDashboard.tsx
  • DashboardResource from dashboard-provider.tsx
  • DashboardResource, EphemeralDashboardResource from DashboardApp.tsx
  • Some important changes in dashboards/src/context/DashboardProvider/DashboardProvider.tsx

Checklist

  • Pull request has a descriptive title and context useful to a reviewer.
  • Pull request title follows the [<catalog_entry>] <commit message> naming convention using one of the
    following catalog_entry values: FEATURE, ENHANCEMENT, BUGFIX, BREAKINGCHANGE, DOC,IGNORE.
  • All commits have DCO signoffs.

UI Changes

  • Changes that impact the UI include screenshots and/or screencasts of the relevant changes.
  • Code follows the UI guidelines.
  • E2E tests are stable and unlikely to be flaky.
    See e2e docs for more details. Common issues include:
    • Is the data inconsistent? You need to mock API requests.
    • Does the time change? You need to use consistent time values or mock time utilities.
    • Does it have loading states? You need to wait for loading to complete.

@shahrokni shahrokni force-pushed the refactor/remove_dashbaord_Resource_core branch 4 times, most recently from facc8a6 to 872354c Compare April 13, 2026 10:16
@shahrokni shahrokni requested a review from jgbernalp April 13, 2026 10:47
@shahrokni shahrokni marked this pull request as ready for review April 13, 2026 10:47
@shahrokni shahrokni requested a review from a team as a code owner April 13, 2026 10:47
Such a decision would affect DashbaordProvider and buildDatasourceProxyUrl
https://github.com/perses/perses/issues/4016
*/
export interface DashboardMinimalResource {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we are moving this out of the spec, why don't we use the same name. It would be a breaking change but for consumers just the import will change.

Suggested change
export interface DashboardMinimalResource {
export interface DashboardResource {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This probably should have its own file.

@jgbernalp jgbernalp changed the title [BREAKINGCHANE] remove dashbaord resource dependecy [BREAKINGCHANGE] remove dashbaord resource dependecy Apr 13, 2026

if (shape === 'cr-v1alpha1') {
const name = dashboard.metadata.name.toLowerCase().replace(/[^a-z0-9-]/g, '-');
const name = (dashboard.metadata.name as string)?.toLowerCase().replace(/[^a-z0-9-]/g, '-');
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should not cast without prior validation or adding a typeGuard, otherwise we will get runtime errors. Is this cast necessary?

*/
export interface DashboardMinimalResource {
kind: DashboardKind;
name: string;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we adding the name if metadata already has it? Which one would be the source of thruth?

proxyUrl: buildDatasourceProxyUrl(datasourceApi, {
project: dashboardResource.metadata.project,
dashboard: dashboardResource.metadata.name,
project: dashboardResource.metadata.project as string,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should avoid casting without verification or fix the underlining types

import { createLinksSlice, LinksSlice } from './links-slice';

export type DashboardKind = 'Dashboard' | 'EphemeralDashboard';
export type DashboardGenericMetaData = Record<string, string | number | string[] | undefined>;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably have a better type for this, this is too generic and reduces type safety (casting)

Copy link
Copy Markdown
Contributor Author

@shahrokni shahrokni Apr 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I picked number and string array for the version and tags fields respectively. If they have no usage here, then the type could be limited to

interface Metadata {
   name: string,
   project: string
}

I myself have some doubts there would be any usage of those fields. WDYT?

@shahrokni shahrokni force-pushed the refactor/remove_dashbaord_Resource_core branch 4 times, most recently from dc6f02e to 2f6e05e Compare April 13, 2026 13:07
Signed-off-by: Seyed Mahmoud SHAHROKNI <seyedmahmoud.shahrokni@amadeus.com>

Signed-off-by: Seyed Mahmoud SHAHROKNI <seyedmahmoud.shahrokni@amadeus.com>

Signed-off-by: Seyed Mahmoud SHAHROKNI <seyedmahmoud.shahrokni@amadeus.com>

Signed-off-by: Seyed Mahmoud SHAHROKNI <seyedmahmoud.shahrokni@amadeus.com>

Signed-off-by: Seyed Mahmoud SHAHROKNI <seyedmahmoud.shahrokni@amadeus.com>

Signed-off-by: Seyed Mahmoud SHAHROKNI <seyedmahmoud.shahrokni@amadeus.com>

Signed-off-by: Seyed Mahmoud SHAHROKNI <seyedmahmoud.shahrokni@amadeus.com>

Signed-off-by: Seyed Mahmoud SHAHROKNI <seyedmahmoud.shahrokni@amadeus.com>

Signed-off-by: Seyed Mahmoud SHAHROKNI <seyedmahmoud.shahrokni@amadeus.com>
@shahrokni shahrokni force-pushed the refactor/remove_dashbaord_Resource_core branch from 2f6e05e to 5b15e50 Compare April 13, 2026 13:22
@shahrokni shahrokni requested a review from jgbernalp April 13, 2026 13:26
import { DashboardSpec } from '@perses-dev/spec';

export type DashboardKind = 'Dashboard' | 'EphemeralDashboard';
export type DashboardMetaData = { name: string; project: string };
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have this type as part of the spec? I believe we are using the same metadata for all resources, so define a new one only for this resource might create discrepancies

Copy link
Copy Markdown
Contributor Author

@shahrokni shahrokni Apr 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't have them in the Spec as far as I know. And it seems they should not be part of the Spec as they are irrelevant there. At the moment the the original ones reside in the Core and should not be moved to the Spec. At least this is what I have understood. If we want to eventually drop the Core, we need to take care of the dependency in Shared.

A solution

What I can do is to flatten the DashboardMetaData and keep its filed in the main object (name and project). But, still not sure if this mitigate your concern. For the Kind however, there is nothing I can do. Kind has been used in the Shared, and has been exposed from the Shared. I am not sure what consequence we may encounter, if we drop it. > The main question is if removing the Kind would be a BREAKINGCHANGE which could be resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants