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

Feature: Support for custom dashboards #1555

Open
akashmane1598 opened this issue Apr 18, 2022 · 6 comments
Open

Feature: Support for custom dashboards #1555

akashmane1598 opened this issue Apr 18, 2022 · 6 comments

Comments

@akashmane1598
Copy link

akashmane1598 commented Apr 18, 2022

Use Case

To enable customising dashboard layouts by passing custom JSON for widgets instead of .dashboard.ts

Proposal

All dashboards in hypertrace are powered through a JSON object which are exported from the respective .dashboard.ts file. This limits the users from creating custom dashboards as per their need.
To add support for custom dashboards we can fetch the JSON config before loading the dashboard screen. For the first phase this config can be served via static JSON files as well

@jaywalker21
Copy link
Contributor

@akashmane2209
Copy link

We plan to add a network call to fetch the custom JSON whose implementation will be somewhat similar to what is done in the snippet.
Screenshot 2022-04-22 at 8 30 57 AM

Need more clarity on where should this be done. Whether in navigable-dashboard.component or application-aware-dashboard.component or to have a wrapper component that would fetch the JSON and pass it down.
Also if there can be any other alternative for this.

@jaywalker21 @anandtiwary @aaron-steinfeld

@aaron-steinfeld
Copy link
Contributor

There's already a dashboard persistence service that would be the place to start looking for this, I believe the current implementation uses local storage, so swapping in a different store that's loading from remote would be straightforward. The problem we still have to solve however is how to make that configurable without modifying source.

@akashmane2209
Copy link

Hey @aaron-steinfeld
Yes, we can swap the store for the dashboard persistence service but need some help on whether to make changes in the navigable dashboard or app aware dashboard because these are shared components across all the repo and we won't be
having custom JSON for all the pages. Also, what are your thoughts on creating a wrapper that would notify the navigable
dashboard component whether to use default JSON or to fetch it from an API?

@aaron-steinfeld
Copy link
Contributor

aaron-steinfeld commented Apr 26, 2022

@akashmane2209 - that's what the persistence service already does, everything you're describing is already built with the exception of remote persistence.
NavigableDashboardComponent takes in a nav location (and optionally a default JSON, but in practice we don't use this any more).

So let's look at API overview:

    <ht-navigable-dashboard
      *htLoadAsync="this.filterConfig$ as filterConfig"
      navLocation="${apiOverviewDashboard.location}"
      [filterConfig]="filterConfig"
    >
    </ht-navigable-dashboard>

NavigableDashboard accepts a constant location (i.e. a key to indicate which dashboard it's looking for), and asks dashboard persistence service to give it the dashboard: this.dashboardPersistenceService.getForLocation(this.navLocation)

At the same time in the API overview module, we import NavigableDashboardModule.withDefaultDashboards(apiOverviewDashboard), registering the default JSON for that location with the dashboard persistence service.

So now the persistence service tries to query the store for that location, falling back to that registered default:

  public getForLocation(locationKey: string): Observable<PersistedDashboard> {
    return this.getById(this.getLocationId(locationKey)).pipe(
      catchError(() => this.getDefaultForLocation(locationKey))
    );
  }

  public getById(id: string): Observable<PersistedDashboard> {
    return this.dashboardStore.read(id);
  }

Sorry for the confusing explanation, hopefully it makes sense! The conclusion I'm driving at though is that by changing to a different implementation of DashboardStore (which is just an interface, currently implemented via a browser local storage version), it can be set up to use a remote URL and have exactly the behavior you're looking for:

export interface DashboardStore {
  read(id: string): Observable<PersistedDashboard>;
  readAll(): Observable<PersistedDashboard>;
  create(dashboard: DashboardCreationData): Observable<PersistedDashboard>;
  update(dashboard: DashboardUpdateData): Observable<PersistedDashboard>;
  upsert(dashboard: DashboardUpsertData): Observable<PersistedDashboard>;
  delete(id: string): Observable<void>;
}

@akashmane1598
Copy link
Author

Okay understood. Let me try updating the service and check.

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

No branches or pull requests

4 participants