[core] Better control over dashboard widgets

Dashboards are generally fairly rigid in their implementation which is good if you just want to pick up the good defaults but bad if you want to customize them for any reason.

Ideally, the API should allow for:

• Adjusting period per-widget (which the dashboard’s periodOverride allows respecting)
• Controlling what widgets are added
• Controlling what metrics are used
• Controlling positioning/sizing of widgets
• Controlling addition of annotations

This may include how widgets are added for custom monitoring, which always uses a calculated width.

[christophercarney]

+1, I agree that the widgets rendered could use a bit more control. This library is amazing and easy to start using because it is opinionated but as a user I should have granular control over what is rendered and how (if I want to).

Rather than release a comprehensive widget control solution does it make sense to try and break it down into smaller deliverables? I think the prevailing sentiment amongst myself and other users of the library is that when it renders widgets that are not useful (for your usecase) it adds unnecessary noise to your overall dashboard.

Could a reasonable first step be to simply allow a user to prevent a certain widget from being rendered all. Then move to exposing the widgets in a way users can customize them, then exposing formatting, etc

[djdawson3]

Hi there,

I realize that a broader discussion on this has been opened recently, but I’m curious if the author would also be open to a short-term fix to support this functionality as I’m trying to change some configurations related to the different dashboards (e.g. different suffix than “-Summary”, different period configurations, etc.).

I looked through the code and it seems that the problem is that the DefaultDashboardFactory constructor is creating dashboards in the constructor and then assigning them to their respective fields which are exposed via methods defined by the IDashboardFactory interface:

• dashboard -> createdDashboard()
• summaryDashboard -> createdSummaryDashboard()
• alarmDashboard -> createdAlarmDashboard()

This means that even if I provide my own dashboard factory, I can’t actually customize the dashboards very much because the call to super() is going to immediately create dashboards which I have no control over other than what is already provided by existing props.

Instead, could we defer creation of these dashboards until a there’s a createDashboard(), createSummaryDashboard() , or createAlarmDashboard() call and instead store necessary information (e.g. rendering preference, start/period overrides, etc.) as class fields? This would allow clients to at least customize some of the content.

What do you think? Is this a reasonable suggestion?