@object-ui/core 17.2.0 → 17.5.0

package/dist/actions/serverActionHandler.d.ts

@@ -0,0 +1,143 @@
+/**
+ * ObjectUI
+ * Copyright (c) 2024-present ObjectStack Inc.
+ *
+ * This source code is licensed under the MIT license found in the
+ * LICENSE file in the root directory of this source tree.
+ */
+/**
+ * `createServerActionHandler` — the core server-action dispatcher factory
+ * (objectui#2904, the follow-up #2896 deferred).
+ *
+ * `ActionSchema.body` (HookBodySchema — L1 expression / L2 sandboxed JS) is the
+ * spec's preferred binding for script actions, and bodies execute SERVER-side:
+ * `POST /api/v1/actions/{object}/{action}` → the runtime sandbox. This client
+ * never interprets a body (L2 needs an isolated VM enforcing capabilities /
+ * `timeoutMs` / `memoryMb`, which a browser cannot provide; L1 is formula-engine
+ * CEL, a different dialect from this package's `${…}` evaluator). The client
+ * DISPATCHES; it does not interpret — see the `ActionDef.body` doc and #2896.
+ *
+ * Until this factory existed, only the console could dispatch: app-shell's
+ * `useConsoleActionRuntime` and `RecordDetailView` each hand-rolled the same
+ * POST (and drifted — objectstack#3913, framework#3935), while every other
+ * `@object-ui/core` consumer fell through to the built-in `executeScript` and
+ * hit a dead end. The factory is deliberately opinion-free about the three
+ * things core has no business deciding (#2904):
+ *
+ * - **auth** — inject `fetch` (an authenticated wrapper: Bearer, tenant,
+ *   cookies — whatever the host's transport needs);
+ * - **base URL** — inject `baseUrl` (a string or a thunk; core inherits no
+ *   bundler env convention like `VITE_SERVER_URL`);
+ * - **object scope** — inject `resolveObject` for the fallback when the action
+ *   declares no `objectName` of its own.
+ *
+ * Everything protocol-shaped lives here, once: name-only action identity
+ * (ADR-0110 D1), the record-id resolution dance (`_rowRecord`, `recordIdField`,
+ * aggregate `_selectedIds`, toolbar-selection fallback with its guards), the
+ * re-entrancy guard, the POST body shape `{ recordId, params }`, and the
+ * `/actions` envelope rule (`interpretActionResponse`).
+ *
+ * Standalone usage:
+ *
+ * ```ts
+ * import { createServerActionHandler } from '@object-ui/core';
+ *
+ * const script = createServerActionHandler({
+ *   fetch: myAuthenticatedFetch,
+ *   baseUrl: 'https://api.example.com',
+ *   resolveObject: () => currentObjectName,
+ *   onRefresh: () => notifyDataChanged(),
+ * });
+ * // Register it — registered handlers beat the built-in executeScript:
+ * // <ActionProvider handlers={{ script }} … />  (or runner.registerHandler('script', script))
+ * ```
+ */
+import type { ActionContext, ActionDef, ActionResult } from './ActionRunner';
+/** The response surface the dispatcher needs — satisfied by a WHATWG `Response`. */
+export interface ServerActionFetchResponse {
+    ok: boolean;
+    status: number;
+    json(): Promise<any>;
+}
+/**
+ * The injected transport. Core has no auth opinion: pass an authenticated
+ * wrapper (e.g. app-shell's `createAuthenticatedFetch()`), not the bare global
+ * `fetch`, unless your deployment really needs no credentials.
+ */
+export type ServerActionFetch = (url: string, init: {
+    method: 'POST';
+    headers: Record<string, string>;
+    body: string;
+}) => Promise<ServerActionFetchResponse>;
+/**
+ * What a record-id resolver reports: a record id (absent for object-scoped
+ * dispatches), or a blocking error the handler returns without POSTing.
+ */
+export interface ServerActionRecordIdResolution {
+    recordId?: unknown;
+    error?: string;
+}
+export type ServerActionRecordIdResolver = (action: ActionDef, context: ActionContext | undefined) => ServerActionRecordIdResolution;
+/**
+ * A dispatch handler produced by {@link createServerActionHandler}. Assignable
+ * to `ActionRunnerHandler` — register it under `'script'` (and, where the host
+ * routes them server-side, other action types).
+ */
+export type ServerActionHandler = (action: ActionDef, context?: ActionContext) => Promise<ActionResult>;
+export interface ServerActionHandlerConfig {
+    /** Authenticated transport — see {@link ServerActionFetch}. */
+    fetch: ServerActionFetch;
+    /**
+     * Server origin prefix (`''`/omitted = same-origin). A thunk is read per
+     * dispatch, so hosts with late-bound configuration can inject one.
+     */
+    baseUrl?: string | (() => string);
+    /**
+     * Fallback object scope when the action declares no `objectName` — e.g. the
+     * current view's object. When neither yields a name the dispatch is `global`.
+     */
+    resolveObject?: (action: ActionDef, context: ActionContext | undefined) => string | undefined;
+    /**
+     * Replace the standard record-id dance ({@link resolveServerActionRecordId})
+     * wholesale — e.g. a record page resolves against ITS record, not a grid
+     * selection.
+     */
+    resolveRecordId?: ServerActionRecordIdResolver;
+    /**
+     * Invoked after a successful dispatch that requests a refresh
+     * (`refreshAfter !== false`) — wire your data invalidation here.
+     */
+    onRefresh?: () => void;
+}
+/**
+ * An action that also mounts on list rows (`list_item`) or record pages is
+ * designed to run against a single record. When such an action is launched
+ * from the list toolbar with nothing selected, there is no record context to
+ * resolve — block up front instead of triggering a run that fails at its
+ * first record-bound step (#2210: "Update requires an ID"). Actions declaring
+ * only object-level locations (e.g. `['list_toolbar']`) are left alone: they
+ * legitimately run without a record.
+ */
+export declare function isRecordScopedAction(action: ActionDef): boolean;
+/**
+ * The standard record-id resolution dance, shared by the dispatcher and by
+ * consumers that need the id BEFORE dispatching (e.g. app-shell's zero-roundtrip
+ * `newTabUrl` fast path). Pure — reads the action/context, mutates nothing.
+ *
+ * Order: explicit `params.recordId` → the stashed `_rowRecord`'s
+ * `recordIdField` (list_item invocations) → the grid's checkbox selection from
+ * the runner context (`selectedRecords`, list_toolbar invocations). An
+ * AGGREGATE bulk dispatch (objectui#3139) carries the whole selection as
+ * `params._selectedIds` — the server reads that array, not `recordId`, so the
+ * selection fallback must not touch it (resolving a recordId would mislabel
+ * the run as record-scoped, and the multi-select guard would block exactly the
+ * selection the dispatch exists to carry). Multi-select is ambiguous for a
+ * single-record action — block with a message; so is zero selection when the
+ * action is record-scoped (see {@link isRecordScopedAction}).
+ */
+export declare function resolveServerActionRecordId(action: ActionDef, context: ActionContext | undefined): ServerActionRecordIdResolution;
+/**
+ * Build a server-action dispatch handler. See the module doc for what the
+ * factory owns and what the config injects.
+ */
+export declare function createServerActionHandler(config: ServerActionHandlerConfig): ServerActionHandler;

package/dist/actions/serverActionHandler.js

@@ -0,0 +1,137 @@
+/**
+ * ObjectUI
+ * Copyright (c) 2024-present ObjectStack Inc.
+ *
+ * This source code is licensed under the MIT license found in the
+ * LICENSE file in the root directory of this source tree.
+ */
+import { interpretActionResponse } from './actionResponse';
+/**
+ * An action that also mounts on list rows (`list_item`) or record pages is
+ * designed to run against a single record. When such an action is launched
+ * from the list toolbar with nothing selected, there is no record context to
+ * resolve — block up front instead of triggering a run that fails at its
+ * first record-bound step (#2210: "Update requires an ID"). Actions declaring
+ * only object-level locations (e.g. `['list_toolbar']`) are left alone: they
+ * legitimately run without a record.
+ */
+export function isRecordScopedAction(action) {
+    const locations = action.locations;
+    if (!Array.isArray(locations))
+        return false;
+    return locations.some((l) => l === 'list_item' || l === 'record_header' || l === 'record_more' || l === 'record_section');
+}
+/**
+ * The standard record-id resolution dance, shared by the dispatcher and by
+ * consumers that need the id BEFORE dispatching (e.g. app-shell's zero-roundtrip
+ * `newTabUrl` fast path). Pure — reads the action/context, mutates nothing.
+ *
+ * Order: explicit `params.recordId` → the stashed `_rowRecord`'s
+ * `recordIdField` (list_item invocations) → the grid's checkbox selection from
+ * the runner context (`selectedRecords`, list_toolbar invocations). An
+ * AGGREGATE bulk dispatch (objectui#3139) carries the whole selection as
+ * `params._selectedIds` — the server reads that array, not `recordId`, so the
+ * selection fallback must not touch it (resolving a recordId would mislabel
+ * the run as record-scoped, and the multi-select guard would block exactly the
+ * selection the dispatch exists to carry). Multi-select is ambiguous for a
+ * single-record action — block with a message; so is zero selection when the
+ * action is record-scoped (see {@link isRecordScopedAction}).
+ */
+export function resolveServerActionRecordId(action, context) {
+    const params = (action.params && !Array.isArray(action.params))
+        ? action.params
+        : {};
+    const rowRecord = params._rowRecord;
+    const recordIdField = action.recordIdField || 'id';
+    let recordId = params.recordId ?? rowRecord?.[recordIdField];
+    const isAggregateDispatch = Array.isArray(params._selectedIds);
+    if (recordId == null && !isAggregateDispatch) {
+        const selected = Array.isArray(context?.selectedRecords) ? context.selectedRecords : [];
+        if (selected.length === 1) {
+            recordId = selected[0]?.[recordIdField];
+        }
+        else if (selected.length > 1) {
+            // The runner's post-execution hook surfaces `error` as a toast.
+            return { error: 'This action runs on a single record — select exactly one row.' };
+        }
+        else if (isRecordScopedAction(action)) {
+            return { error: 'This action runs on a single record — select a row first.' };
+        }
+    }
+    return { recordId: recordId ?? undefined };
+}
+/**
+ * Build a server-action dispatch handler. See the module doc for what the
+ * factory owns and what the config injects.
+ */
+export function createServerActionHandler(config) {
+    const { fetch: dispatchFetch, resolveObject, onRefresh } = config;
+    const resolveRecordId = config.resolveRecordId ?? resolveServerActionRecordId;
+    // Guards against double-firing a server action (slow SSO handoff, etc.).
+    // Handler-instance state: keep the produced handler stable for its guard to
+    // span invocations.
+    const inFlight = new Set();
+    return async function serverActionDispatch(action, context) {
+        // [ADR-0110 D1] The URL identifies the action by its declarative `name`,
+        // never by `target`. `target` is a BINDING EXPRESSION — the handler's
+        // registration key here, but a URL / flow id / FormView name for other
+        // types, `${param.X}`-interpolatable, and legitimately non-unique — so it
+        // cannot identify a declaration. Posting it (the old `target || name`)
+        // meant the server resolved NO declaration for a target-bound action and
+        // silently skipped both the ADR-0066 D4 capability gate and the ADR-0104
+        // param contract (framework#3935). The server derives the handler key from
+        // the declaration it resolves by name.
+        const actionName = action.name;
+        if (!actionName) {
+            return { success: false, error: 'Action has no name — a server action must declare one' };
+        }
+        // The row record is a CLIENT-side stash (list_item invocations park it
+        // under `params._rowRecord` for param defaults and id resolution) — never
+        // part of the server contract, so it is stripped from the POSTed params.
+        const params = (action.params && !Array.isArray(action.params))
+            ? { ...action.params }
+            : {};
+        delete params._rowRecord;
+        const resolution = resolveRecordId(action, context);
+        if (resolution.error) {
+            return { success: false, error: resolution.error };
+        }
+        const recordId = resolution.recordId;
+        // Re-entrancy guard.
+        const inflightKey = `${actionName}:${recordId ?? ''}`;
+        if (inFlight.has(inflightKey)) {
+            return { success: false, error: 'Action already in progress' };
+        }
+        inFlight.add(inflightKey);
+        try {
+            const baseUrl = typeof config.baseUrl === 'function' ? config.baseUrl() : (config.baseUrl ?? '');
+            const objectName = action.objectName || resolveObject?.(action, context) || 'global';
+            const res = await dispatchFetch(`${baseUrl}/api/v1/actions/${encodeURIComponent(objectName)}/${encodeURIComponent(actionName)}`, {
+                method: 'POST',
+                headers: { 'Content-Type': 'application/json' },
+                body: JSON.stringify({ recordId, params }),
+            });
+            const json = await res.json().catch(() => null);
+            // The `/actions` envelope rule, once — see ./actionResponse.
+            const outcome = interpretActionResponse(res, json, `Action "${actionName}"`);
+            if (!outcome.ok) {
+                // Don't toast here — the ActionRunner's post-execution hook surfaces
+                // `error` as a toast; a handler-side toast double-fires it.
+                return { success: false, error: outcome.error };
+            }
+            const shouldRefresh = action.refreshAfter !== false;
+            if (shouldRefresh)
+                onRefresh?.();
+            // `data` carries the ACTION ENVELOPE (`{ success, data }`), the level
+            // `ActionResult.data` has always carried; consumers reading the
+            // handler's own return value go through `readActionPayload`.
+            return { success: true, data: outcome.envelope, reload: shouldRefresh };
+        }
+        catch (error) {
+            return { success: false, error: error.message };
+        }
+        finally {
+            inFlight.delete(inflightKey);
+        }
+    };
+}

package/dist/data-scope/ViewDataProvider.d.ts

@@ -18,6 +18,7 @@
  * @module data-scope
  * @packageDocumentation
  */
+import { type ElementDataSourceConfig, type ElementSavedView } from './element-data-source.js';
 /** ViewData union — matches @objectstack/spec ViewDataSchema */
 export type ViewDataConfig = {
     provider: 'object';
@@ -38,17 +39,12 @@ export type ViewDataConfig = {
     provider: 'value';
     items: any[];
 };
-/** Element-level data source — matches @objectstack/spec ElementDataSourceSchema */
-export interface ElementDataSourceConfig {
-    object: string;
-    view?: string;
-    filter?: Record<string, any>;
-    sort?: Array<{
-        field: string;
-        order: 'asc' | 'desc';
-    }>;
-    limit?: number;
-}
+/**
+ * Re-exported from `./element-data-source.js`, where the binding's type now
+ * lives alongside the logic that consumes it. Kept on this module path because
+ * that is where it was declared before objectstack#5576.
+ */
+export type { ElementDataSourceConfig };
 /** Fetcher interface — consumers provide the actual fetch implementation */
 export interface DataFetcher {
     /** Fetch records for an object */
@@ -82,6 +78,19 @@ export interface DataFetcher {
         headers?: Record<string, string>;
         body?: any;
     }): Promise<any>;
+    /**
+     * Fetch the object's saved views, so an `ElementDataSource.view` name can be
+     * resolved to real columns / filter / sort (objectstack#5576).
+     *
+     * Optional because most fetchers only read records. A fetcher WITHOUT it
+     * cannot honour a named view, and {@link ViewDataProvider.resolveElementDataSource}
+     * says so in `error` rather than dropping the key — the whole point of #5576
+     * is that a `view` the runtime cannot apply must never look applied.
+     *
+     * Either shape stored views come in is accepted: a map keyed by view id, or
+     * the array of overlay rows an adapter's `listViews()` returns.
+     */
+    fetchViews?(object: string): Promise<Record<string, ElementSavedView> | ElementSavedView[]>;
 }
 /** Resolved data result */
 export interface ResolvedData {
@@ -138,6 +147,22 @@ export declare class ViewDataProvider {
     private resolveApi;
     /** Resolve object-based data (metadata-driven) */
     private resolveObject;
-    /** Resolve element-level data source */
+    /**
+     * Resolve an element-level data source (`PageComponentSchema.dataSource`).
+     *
+     * `view` is HONOURED here, not dropped. Until objectstack#5576 this method
+     * forwarded `filter`/`sort`/`limit` and silently discarded `view`, so a page
+     * component that named a saved view got every record the object had — the
+     * declared binding was inert while looking applied.
+     *
+     * Three outcomes, all explicit:
+     *  - no `view` → unchanged behaviour, the binding's own keys are forwarded;
+     *  - `view` resolved → its columns become the `fields` projection and its
+     *    filter/sort/limit the baseline the binding's keys compose with (see
+     *    {@link composeElementDataSource} for the per-key rule);
+     *  - `view` unresolvable, or the fetcher cannot list views at all → an
+     *    `error` naming the view and what the object does have. NOT an empty
+     *    result, and NOT a silent fall back to the unfiltered object.
+     */
     resolveElementDataSource(config: ElementDataSourceConfig): Promise<ResolvedData>;
 }

package/dist/data-scope/ViewDataProvider.js

@@ -5,6 +5,20 @@
  * This source code is licensed under the MIT license found in the
  * LICENSE file in the root directory of this source tree.
  */
+/**
+ * @object-ui/core - View Data Provider
+ *
+ * Resolves @objectstack/spec ViewData discriminated union into
+ * a unified data access interface. Supports three data modes:
+ *
+ * 1. 'object' — Metadata-driven via ObjectStack API (object name → fields/records)
+ * 2. 'api' — Custom REST API endpoints (read/write URLs)
+ * 3. 'value' — Static data (pre-loaded items array)
+ *
+ * @module data-scope
+ * @packageDocumentation
+ */
+import { collectSavedViews, composeElementDataSource, elementDataSourceViewNotFoundMessage, resolveSavedView, } from './element-data-source.js';
 /** Extract records array from various common API response shapes */
 function extractRecords(data) {
     if (Array.isArray(data))
@@ -142,12 +156,76 @@ export class ViewDataProvider {
             };
         }
     }
-    /** Resolve element-level data source */
+    /**
+     * Resolve an element-level data source (`PageComponentSchema.dataSource`).
+     *
+     * `view` is HONOURED here, not dropped. Until objectstack#5576 this method
+     * forwarded `filter`/`sort`/`limit` and silently discarded `view`, so a page
+     * component that named a saved view got every record the object had — the
+     * declared binding was inert while looking applied.
+     *
+     * Three outcomes, all explicit:
+     *  - no `view` → unchanged behaviour, the binding's own keys are forwarded;
+     *  - `view` resolved → its columns become the `fields` projection and its
+     *    filter/sort/limit the baseline the binding's keys compose with (see
+     *    {@link composeElementDataSource} for the per-key rule);
+     *  - `view` unresolvable, or the fetcher cannot list views at all → an
+     *    `error` naming the view and what the object does have. NOT an empty
+     *    result, and NOT a silent fall back to the unfiltered object.
+     */
     async resolveElementDataSource(config) {
-        return this.resolve({ provider: 'object', object: config.object }, {
-            filter: config.filter,
-            sort: config.sort,
-            limit: config.limit,
+        let view;
+        if (config.view) {
+            if (!this.fetcher?.fetchViews) {
+                return {
+                    records: [],
+                    total: 0,
+                    provider: 'object',
+                    loading: false,
+                    error: `dataSource.view "${config.view}" cannot be resolved: this data ` +
+                        `fetcher does not implement fetchViews().`,
+                };
+            }
+            let views;
+            try {
+                views = collectSavedViews(await this.fetcher.fetchViews(config.object));
+            }
+            catch (error) {
+                return {
+                    records: [],
+                    total: 0,
+                    provider: 'object',
+                    loading: false,
+                    error: error.message,
+                };
+            }
+            view = resolveSavedView(views, config.view, config.object);
+            if (!view) {
+                return {
+                    records: [],
+                    total: 0,
+                    provider: 'object',
+                    loading: false,
+                    error: elementDataSourceViewNotFoundMessage(config.object, config.view, Object.keys(views)),
+                };
+            }
+        }
+        const composed = composeElementDataSource(config, view);
+        const fields = Array.isArray(composed.columns)
+            ? composed.columns.filter((c) => typeof c === 'string' && !!c)
+            : undefined;
+        return this.resolve({ provider: 'object', object: composed.object }, {
+            // `DataFetcher.fetchRecords`'s `filter` is declared
+            // `Record<string, any>`, which predates the three filter shapes that
+            // legitimately circulate here: a MongoDB-style condition object, an
+            // ObjectQL AST node array, and a spec `ViewFilterRule[]`. The last two
+            // are arrays, so a saved view's filter does not fit the declared option
+            // — the cast is that gap, not a coercion. Widening the declared option
+            // is a separate change with its own consumers.
+            filter: composed.filter,
+            sort: composed.sort,
+            limit: composed.limit,
+            ...(fields && fields.length > 0 ? { fields } : {}),
         });
     }
 }

package/dist/data-scope/element-data-source.d.ts

@@ -0,0 +1,113 @@
+/**
+ * ObjectUI
+ * Copyright (c) 2024-present ObjectStack Inc.
+ *
+ * This source code is licensed under the MIT license found in the
+ * LICENSE file in the root directory of this source tree.
+ */
+/** Sort entry, as both the spec's `SortItem` and objectui's view configs spell it. */
+export interface ElementDataSourceSort {
+    field: string;
+    order: 'asc' | 'desc';
+}
+/**
+ * Element-level data source — matches `@objectstack/spec` `ElementDataSourceSchema`.
+ *
+ * `filter` is typed `unknown` rather than the spec's `FilterCondition` because
+ * three shapes legitimately reach a renderer here (a MongoDB-style condition
+ * object, an ObjectQL AST node array, a spec `ViewFilterRule[]`) and
+ * {@link mergeFilterNodes} is the single sink that lowers all three. Narrowing
+ * the type here would only move the cast, not remove it.
+ */
+export interface ElementDataSourceConfig {
+    object: string;
+    view?: string;
+    filter?: unknown;
+    sort?: ElementDataSourceSort[];
+    limit?: number;
+}
+/**
+ * The subset of a saved view's config that an `ElementDataSource` `view` name
+ * contributes. Deliberately loose: stored view metadata is user data and carries
+ * both the spec vocabulary and the legacy objectui spellings that
+ * `normalizeListViewSchema` folds at the component boundary.
+ */
+export type ElementSavedView = Record<string, unknown>;
+/** What {@link composeElementDataSource} produces for a renderer to consume. */
+export interface ComposedElementDataSource {
+    /** Object to query. */
+    object: string;
+    /** Columns the named view shows; absent when no view was named. */
+    columns?: unknown;
+    /** View filter AND binding filter, combined; `undefined` when neither. */
+    filter?: unknown;
+    /** Binding sort if given, else the view's. */
+    sort?: unknown;
+    /** Binding limit if given, else the view's page size. */
+    limit?: number;
+    /** The view's render kind (grid / kanban / …), when the view declares one. */
+    viewType?: string;
+}
+/**
+ * Is this value the spec's `dataSource` METADATA, rather than a runtime
+ * data-source adapter?
+ *
+ * This guard exists because the two collide by name and the collision was live:
+ * `SchemaRenderer` spreads every non-metadata schema key onto the component as a
+ * React prop, so a spec-compliant `dataSource: { object, view }` on a page
+ * component landed on `ListView`'s `dataSource` PROP — which is the injected
+ * adapter — and shadowed it. The first `dataSource.find(…)` then threw
+ * `dataSource.find is not a function`, which the list reported as
+ * "Couldn't load records": writing the binding the spec documents BROKE the
+ * component (objectstack#5576).
+ *
+ * The test is positive on the metadata rather than negative on the adapter: a
+ * binding is a plain object with a non-empty string `object` and no `find`
+ * method. An adapter never has a string `object`; metadata never has `find`.
+ */
+export declare function isElementDataSourceConfig(value: unknown): value is ElementDataSourceConfig;
+/**
+ * Flatten every place saved views for one object can live into `id → config`.
+ *
+ * Two sources are real and both are read, in the order app-shell's `ObjectView`
+ * reads them: the object definition's embedded `listViews` / `list_views` map
+ * (metadata-defined) and the metadata overlay rows an adapter returns from
+ * `listViews()` (user-defined). Later sources win, so a saved view shadows a
+ * metadata view of the same id — the same precedence `ObjectView` applies when
+ * it dedups its tab list.
+ *
+ * Accepts a record keyed by view id or an array of view configs (overlay rows
+ * are an array and carry their identity in `name`, falling back to `id`).
+ */
+export declare function collectSavedViews(...sources: unknown[]): Record<string, ElementSavedView>;
+/**
+ * Find the saved view a `dataSource.view` name refers to.
+ *
+ * Name matching is {@link resolveViewId}'s — the same short/qualified tolerance
+ * the object page applies to a URL-requested view — so a name that works in one
+ * surface works in the other. Returns `undefined` when nothing matches; the
+ * caller must REPORT that rather than fall back to the object's default view.
+ * Silently widening a named view to "all records" is the failure mode this whole
+ * binding exists to remove.
+ */
+export declare function resolveSavedView(views: Record<string, ElementSavedView>, requested: string | undefined | null, object: string): ElementSavedView | undefined;
+/**
+ * Compose an `ElementDataSource` binding with the saved view it names.
+ *
+ * Pure — the caller resolves the view (see {@link resolveSavedView}) and owns
+ * the "named a view that does not exist" decision. Passing `undefined` /`null`
+ * for `view` composes a binding with no view, which is exactly the pre-#5576
+ * behaviour for the other four keys.
+ *
+ * See the module doc for the per-key rule table; `filter` is the only key that
+ * combines rather than overrides, because the spec describes the binding's
+ * filter as *additional*.
+ */
+export declare function composeElementDataSource(config: ElementDataSourceConfig, view?: ElementSavedView | null): ComposedElementDataSource;
+/**
+ * The message shown when `dataSource.view` names a view the object does not
+ * have. Built here so the render path and `ViewDataProvider` report the same
+ * defect the same way, and so the known-view list (the thing that actually gets
+ * an author unstuck) is never omitted by one caller.
+ */
+export declare function elementDataSourceViewNotFoundMessage(object: string, view: string, knownViews: readonly string[]): string;