Dashboard extension API cannot set a default filter on a native list page

[kingpeti]

The gap

DashboardDataTableExtensionDefinition (3.7.1) lets an extension change which columns a native list page shows, but not which rows it opens on. viewOptionDefaults is typed and documented as visibility and order only:

// framework/extension-api/types/data-table.ts
export type DashboardDataTableViewOptionDefaults = {
    columnVisibility?: VisibilityState;
    columnOrder?: ColumnOrderState;
};

The definition has six members (pageId, blockId, bulkActions, extendListDocument, displayComponents, viewOptionDefaults), and a search of framework/extension-api/ turns up no filter-related API at all. Filter state lives in tableSettings.columnFilters, owned by ListPage, and no extension API writes it.

Use case

Our catalogue holds two kinds of Product, distinguished by a product-type facet: individual meals, and bundles composed of them. Operators work with meals essentially all of the time. We would like /products to open filtered to product-type: meal, while leaving it an ordinary, dismissible filter the operator can clear.

We would rather not own the route. Everything else the page does (search, paging, bulk actions, the detail link, custom-field columns) is exactly what we want, and reimplementing it as a custom page to change one default is a lot of surface to keep in step with upstream for one line of intent.

Possible shape

Either a columnFilters member alongside the two that exist:

viewOptionDefaults: {
    columnVisibility: { /* ... */ },
    columnFilters: [{ id: 'facetValueId', value: { in: [mealFacetValueId] } }],
}

or a separate defaultFilter member on the data-table extension. Either way the properties that matter are that it seeds the operator's initial state rather than constraining the query, and that the operator can clear it.

Alternatives considered

• Writing tableSettings.columnFilters from an extension. Writes into another component's user-preference store, and would fight the operator's own filter on every load rather than seeding it once.
• transformVariables on the list query. Not reachable without owning the route, and it would make the filter mandatory rather than a default.
• Linking to /products?filters=…. Moves the requirement onto whoever types the URL, and does nothing for an operator who clicks the nav item.
• A custom page. Works, and is the maintenance we are trying to avoid.

Environment

@vendure/dashboard 3.7.1, Vendure 3.7.1.

Happy to open a PR if a maintainer indicates which of the two shapes fits the extension API's direction.