Dashboard hooks

Two hooks behind the dashboard: the store holding the user's widget layout, and the lookup that turns a widget type into its definition. Both ship in habarico-enterprise — the free package cannot compose a schema-driven dashboard, so neither had a caller there.

useDashboardStore

Reads and writes the current user's dashboard layout.

import {useDashboardStore} from 'habarico-enterprise';

const {widgets, setWidgets} = useDashboardStore();

// drop a widget from outside the dashboard UI
setWidgets(widgets.filter((w) => w.id !== 'stale-widget'));

Name	Type	Description
widgets	WidgetConfig[]	The configured widgets with their layouts; empty by default
setWidgets	(widgets: WidgetConfig[]) => void	Replaces the whole list

The layout lives in React Admin's store under preferences.dashboard, so it follows the same persistence as every other preference: local by default, and synced to the backend when a service sets syncPreferences: true. The key is a free preference on both backends, but only the paid dashboard writes it, so it is not in the free PREFERENCES_WHITELIST — EnterpriseSchemaAdmin adds it through SchemaAdmin's preferencesWhitelist prop. An application wiring the dashboard by hand adds it the same way:

preferencesWhitelist={[...PREFERENCES_WHITELIST, 'preferences.dashboard']}

caution

setWidgets throws when two widgets overlap — the layouts are checked pairwise before they are stored. Compute a non-overlapping layout before calling it; the grid in the dashboard UI does this for you, hand-written code has to do it itself.

useGetWidget

Resolves a widget type to its WidgetDefinition through the widget catalogue in context — the paid catalogue unless a WidgetCatalogProvider above it says otherwise. It ships in habarico-enterprise, with the dashboard that calls it.

import {useGetWidget} from 'habarico-enterprise';

const getWidget = useGetWidget();
const definition = getWidget({type: 'bar', resource: 'eshop/order'});

Name	Type	Description
type (required)	WidgetType	The widget type to resolve
resource	string	Resource the widget will read, when the type needs one

It returns undefined when the catalogue does not claim the type — that is how the add-widget wizard knows a type is unavailable.

See also

• Adding a new widget type — writing the provider this resolves against
• Widget configuration — what a WidgetConfig holds
• createBackendStore — how the layout is synced