docs: dashboard editing example #3983
Conversation
There was a problem hiding this comment.
There's another issue with the Lit example where clicking "Apply" after moving widgets, the dashboard reverts to the order.
There was a problem hiding this comment.
It seems like this assumption isn't true for the Lit version:
docs/frontend/demo/component/dashboard/dashboard-editable.ts
Lines 49 to 51 in a24ab8a
There was a problem hiding this comment.
I've added listeners for all modifications to update the widgets state, which solves the issue.
As discussed internally, there is a separate issue with widgets losing focus in move mode, but it doesn't look like it's an issue with the example setup.
| .renderer="${this.renderWidget}" | ||
| @dashboard-item-moved="${(e: DashboardItemMovedEvent<WidgetConfig>) => { | ||
| // Store updated widgets after user has modified them | ||
| this.widgets = e.detail.items as WidgetConfig[]; |
There was a problem hiding this comment.
Used a cast here so that the example doesn't have to deal with the Array<DashboardSectionItem | DashboardItem> type. This needs to happen somewhere in this component, otherwise we'd also need to deal with this structure in the Java service used in the example. Not great, but having to deal with sections in an example that doesn't use them seems worse?
| } | ||
|
|
||
| // Render function should be memoized to avoid unnecessary re-renders | ||
| const renderWidget = useCallback(({ item }: DashboardReactRendererProps<WidgetConfig>) => { |
There was a problem hiding this comment.
As discussed, put the renderer function into a useCallback to avoid re-rendering widgets.
| // Stores the current dashboard configuration. The Dashboard component will | ||
| // modify this array in place when editing, so there is no need to update it | ||
| // using events. |
Adds dashbard example for an editable dashboard that allows persisting and loading its configuration.