Flexible dashboard toolbar actions configuration

[chintankavathia]

Overview

Flexible dashboard currently allows providing toolbar actions as primaryEditActions and secondaryEditActions. The current approach for configuring this actions is through SiWidgetStorage by overriding getToolbarMenuItems and returning

{
   primary: Observable<(MenuItem | DashboardToolbarItem)[]>;
   secondary: Observable<(MenuItem | DashboardToolbarItem)[]>;
 }

Current Implementation drawbacks

• SiWidgetStorage is meant to handle widget persistence and loading from storage system. Adding getToolbarMenuItems into that abstraction layer deviates its sole purpose.
• In case of multiple dashboards with their own custom actions, getToolbarMenuItems becomes very complex with multiple conditions
• Returning observables from getToolbarMenuItems creates complex rxjs handling on the component side.

Proposal

• Remove/deprecate getToolbarMenuItems from SiWidgetStorage contract
• Introduce signal inputs for primaryEditActions and secondaryEditActions on si-flexible-dashboard component.
• signal inputs than can easily used to compute menu items simplifying this complex setup

[chintankavathia]

@timowolf WDYT

[timowolf]

@chintankavathia Yes, it makes totally sense to refine.

• You proposal makes sense to provide those on dashboard API.
• But an app might want to provide it centrally for multiple dashboards. You you think it makes sense to introduce an additional InjectionToken?

[chintankavathia]

Providing it centrally doesn't have much value IMO, because the callback actions will always be dashboard specific in most of the cases. Also projects can create their own injectable and share across multiple dashboards.

e.g

@Injectable()
CommonActions {
   primaryActions = ...
   secondaryActions = ...
}

@Component({
   template: `<si-flexible-dashboard [primaryActions]="primaryActions">`
})
Dashboard1 {
   primaryActions = inject(CommonActions).primaryActions;
}

[kfenner]

@chintankavathia What you propose makes perfect sense to me 👍

[timowolf]

The injection point should not be used in the wrapper component. Should be centrally provided as now, and work with optional ids of the dashboard.

[chintankavathia]

Closing this. Implemented as per proposal.