@globalpayments-private/gpds-pattern-web-react 0.0.0-stage → 0.1.1-pr.52.gae8887e

package/dist/components.d.ts

@@ -0,0 +1,12 @@
+/**
+ * This file was automatically generated by the Stencil React Output Target.
+ * Changes to this file may cause incorrect behavior and will be lost if the code is regenerated.
+ */
+export { GpAdmin } from './gp-admin.js';
+export { GpPatternList } from './gp-pattern-list.js';
+export { GpPatternRecord } from './gp-pattern-record.js';
+export { GpPatternReferenceInput } from './gp-pattern-reference-input.js';
+export { GpPatternWizard } from './gp-pattern-wizard.js';
+export { GpResource } from './gp-resource.js';
+export { UdsPatternLoginCard } from './uds-pattern-login-card.js';
+export { UdsPatternLoginPage } from './uds-pattern-login-page.js';

package/dist/components.js

@@ -0,0 +1,13 @@
+/**
+ * This file was automatically generated by the Stencil React Output Target.
+ * Changes to this file may cause incorrect behavior and will be lost if the code is regenerated.
+ */
+/* eslint-disable */
+export { GpAdmin } from './gp-admin.js';
+export { GpPatternList } from './gp-pattern-list.js';
+export { GpPatternRecord } from './gp-pattern-record.js';
+export { GpPatternReferenceInput } from './gp-pattern-reference-input.js';
+export { GpPatternWizard } from './gp-pattern-wizard.js';
+export { GpResource } from './gp-resource.js';
+export { UdsPatternLoginCard } from './uds-pattern-login-card.js';
+export { UdsPatternLoginPage } from './uds-pattern-login-page.js';

package/dist/composition/admin.d.ts

@@ -0,0 +1,60 @@
+import { type ReactElement, type ReactNode } from 'react';
+import type { UdsAdminLabels, UdsAuthProvider, UdsDataProvider, UdsNotificationProvider, UdsQueryProvider, UdsRouterProvider } from '@globalpayments-private/gpds-pattern-web';
+import { type UdsPageBuilder } from './custom-routes';
+/**
+ * `Admin`: the root of the composition layer, a thin rename of what
+ * `gp-admin` already was (ADR 0012 already treats `<gp-admin><gp-resource/>
+ * </gp-admin>` as a composition, not as config). `Admin` exists only because
+ * real react-admin's root is called `<Admin>`
+ * (https://marmelab.com/react-admin/Tutorial.html) — see
+ * `docs/specs/north-star-composition.md` §9.
+ *
+ * `children` are forwarded untouched: a `<Resource>` passed here renders as a
+ * real `<gp-resource>` child element, which is how `gp-admin` discovers its
+ * resources today (`admin.config.resources` is the alternative path, not a
+ * replacement — see `UdsAdminConfig.resources`'s own doc).
+ *
+ * `<CustomRoutes>` is the one child `Admin` also *reads*, because a custom
+ * page is half configuration (`config.pages`) and half slotted content
+ * (`<section slot="page-…">`). Both halves are produced here so the consumer
+ * only ever writes react-admin's tree — see `custom-routes.tsx` for why that
+ * is the one marker pair that renders.
+ *
+ * Written with `createElement` rather than JSX: this package's shared Jest
+ * config compiles every `.tsx` with Stencil's own `h`-pragma transform (the
+ * rest of `src/` needs exactly that), so JSX syntax here would silently
+ * target the wrong runtime under test. `createElement` is what JSX compiles
+ * to either way.
+ */
+export interface AdminProps {
+    data?: UdsDataProvider;
+    auth?: UdsAuthProvider;
+    /**
+     * The query cache, mirroring react-admin's `queryClient`
+     * (https://marmelab.com/react-admin/Admin.html#queryclient).
+     */
+    query?: UdsQueryProvider;
+    /**
+     * The router, mirroring react-admin's `basename`/router configuration. A
+     * demo served from GitHub Pages needs `createHistoryRouter({ hash: true })`
+     * here, so this is not an advanced seam — it is the first thing a deployed
+     * app sets.
+     */
+    router?: UdsRouterProvider;
+    /** Notifications, mirroring react-admin's `notification` slot. */
+    notifications?: UdsNotificationProvider;
+    /** Copy overrides, the narrow part of react-admin's `i18nProvider`. */
+    labels?: Partial<UdsAdminLabels>;
+    /**
+     * The landing screen, mirroring react-admin's `dashboard`
+     * (https://marmelab.com/react-admin/Admin.html#dashboard).
+     *
+     * Takes a React node or a `() => Node` builder, for the same reason
+     * `<Route element>` does: this library's framework-neutral pages return
+     * plain DOM and are mirrored unchanged into the vanilla, Vue and Angular
+     * variants of the same demo (ADR 0017, ADR 0030).
+     */
+    dashboard?: ReactNode | UdsPageBuilder;
+    children?: ReactElement | ReactElement[];
+}
+export declare function Admin({ data, auth, query, router, notifications, labels, dashboard, children, }: AdminProps): ReactElement;

package/dist/composition/admin.js

@@ -0,0 +1,29 @@
+import { createElement } from 'react';
+// Relative, not the `./react` package subpath: that subpath has no `require`
+// condition (ESM-only, matching the rest of the generated bindings), which
+// would break loading this file under Jest's CommonJS test runner.
+import { GpAdmin } from '@globalpayments-private/gpds-pattern-web-react';
+import { mountBuilder, pageSectionsFrom, pagesFrom, routesFromChildren, } from './custom-routes';
+export function Admin({ data, auth, query, router, notifications, labels, dashboard, children, }) {
+    const routes = routesFromChildren(children);
+    const config = {
+        data,
+        auth,
+        query,
+        router,
+        notifications,
+        labels,
+        pages: pagesFrom(routes),
+    };
+    return createElement(GpAdmin, { config, hasDashboard: dashboard !== undefined }, children, ...pageSectionsFrom(routes), ...dashboardSection(dashboard));
+}
+/** The `<div slot="dashboard">` the shell renders its landing screen into, when there is one. */
+function dashboardSection(dashboard) {
+    if (dashboard === undefined) {
+        return [];
+    }
+    const isBuilder = typeof dashboard === 'function';
+    return [
+        createElement('div', { key: 'dashboard', slot: 'dashboard', ...(isBuilder ? { ref: mountBuilder(dashboard) } : {}) }, isBuilder ? undefined : dashboard),
+    ];
+}

package/dist/composition/children.d.ts

@@ -0,0 +1,3 @@
+import type { ReactNode } from 'react';
+/** `React.Children.toArray`, without taking a hard dependency on the `React` default export. */
+export declare function reactChildrenToArray(children: ReactNode): ReactNode[];

package/dist/composition/children.js

@@ -0,0 +1,7 @@
+/** `React.Children.toArray`, without taking a hard dependency on the `React` default export. */
+export function reactChildrenToArray(children) {
+    if (children === undefined || children === null || children === false) {
+        return [];
+    }
+    return Array.isArray(children) ? children.flat(Infinity) : [children];
+}

package/dist/composition/custom-routes.d.ts

@@ -0,0 +1,88 @@
+import { type ReactElement, type ReactNode } from 'react';
+import type { UdsAdminPageDefinition } from '@globalpayments-private/gpds-pattern-web';
+/**
+ * `CustomRoutes` and `Route`: the composition spelling of
+ * `UdsAdminConfig.pages`, mirroring real react-admin's
+ * https://marmelab.com/react-admin/CustomRoutes.html:
+ *
+ * ```tsx
+ * <Admin data={data}>
+ *   <Resource name="merchants">…</Resource>
+ *   <CustomRoutes>
+ *     <Route path="/reports/settlement" name="settlement" label="Settlement" element={buildSettlementReport} />
+ *   </CustomRoutes>
+ * </Admin>
+ * ```
+ *
+ * ## Why these are the one pair of markers that really render
+ *
+ * Every other marker in this layer is read and discarded, because what it
+ * describes is *configuration* that ends up on a `config` prop. A custom page
+ * is not only configuration: `gp-admin` matches `pages[].path` and then
+ * renders whatever is in the matching **named slot** — `{ name: 'settlement' }`
+ * pairs with `<section slot="page-settlement">`. The definition and the
+ * content are two halves of one thing, and only one half is a plain object.
+ *
+ * So `Admin` does both: it reads `<CustomRoutes>` into `config.pages`, and it
+ * renders each `<Route>`'s `element` into the `<section slot="page-…">` the
+ * shell will look for. The consumer writes react-admin's tree and never sees
+ * the slot convention, which is the point.
+ *
+ * ## Why `element` accepts a DOM builder as well as a React node
+ *
+ * React-admin's `element` is necessarily a React element — react-admin is a
+ * React framework. This library is not: its demos' custom pages are
+ * framework-neutral builders that return plain DOM and reach the shell
+ * through `requestContext` (ADR 0017), and they are mirrored unchanged into
+ * the vanilla, Vue and Angular variants of the same demo. Accepting only a
+ * React node would mean every custom page had to be rewritten as a React tree
+ * purely to satisfy the shape of a tag — which would end the single mirrored
+ * source those demos are built on, to buy nothing.
+ *
+ * So `element` takes either: a React node, rendered as the slot's children;
+ * or a `() => Node` builder, mounted into the slot through a ref on first
+ * attach. See ADR 0030.
+ */
+/** A builder that returns a plain DOM node — what this library's framework-neutral pages are. */
+export type UdsPageBuilder = () => Node;
+export interface RouteProps extends Omit<UdsAdminPageDefinition, 'name'> {
+    /**
+     * The page's stable key, used for the slot name (`page-<name>`).
+     *
+     * Defaults to a slug of `path`, so the common case needs only `path` and
+     * `element`, as in react-admin.
+     */
+    name?: string;
+    /** The page's content: a React node, or a builder returning a DOM node. */
+    element: ReactNode | UdsPageBuilder;
+}
+/** Marker component for one custom page. Never rendered directly — see the module doc. */
+export declare function Route(_props: RouteProps): null;
+export interface CustomRoutesProps {
+    /** `<Route>` children. */
+    children?: ReactNode;
+}
+/** Marker component for the custom-page set. Never rendered directly — see the module doc. */
+export declare function CustomRoutes(_props: CustomRoutesProps): null;
+/** One `<Route>`, resolved into the definition and the content the shell needs separately. */
+interface ResolvedRoute {
+    definition: UdsAdminPageDefinition;
+    element: ReactNode | UdsPageBuilder;
+}
+/** Reads every `<CustomRoutes>` child of an `<Admin>` into its `<Route>`s, in order. */
+export declare function routesFromChildren(children: ReactNode): ResolvedRoute[];
+/** The `pages` member a resolved route set stands for, or `undefined` when there are none. */
+export declare function pagesFrom(routes: ResolvedRoute[]): UdsAdminPageDefinition[] | undefined;
+/**
+ * The `<section slot="page-…">` elements `gp-admin` renders custom pages into.
+ *
+ * A React-node `element` becomes the section's children. A builder is mounted
+ * through a ref: the section is created empty and the builder's node appended
+ * once, on attach. The ref deliberately rebuilds nothing on re-render — these
+ * pages own their own DOM and their own updates (ADR 0017), and re-running a
+ * builder under them would throw away the state they are holding.
+ */
+export declare function pageSectionsFrom(routes: ResolvedRoute[]): ReactElement[];
+/** A ref callback that appends the builder's node once, the first time the host attaches. */
+export declare function mountBuilder(build: UdsPageBuilder): (host: Element | null) => void;
+export {};

package/dist/composition/custom-routes.js

@@ -0,0 +1,76 @@
+import { createElement } from 'react';
+import { reactChildrenToArray } from './children';
+/** Marker component for one custom page. Never rendered directly — see the module doc. */
+export function Route(_props) {
+    return null;
+}
+/** Marker component for the custom-page set. Never rendered directly — see the module doc. */
+export function CustomRoutes(_props) {
+    return null;
+}
+/** Reads every `<CustomRoutes>` child of an `<Admin>` into its `<Route>`s, in order. */
+export function routesFromChildren(children) {
+    const resolved = [];
+    reactChildrenToArray(children).forEach((child) => {
+        if (!isElementOfType(child, CustomRoutes)) {
+            return;
+        }
+        reactChildrenToArray(child.props.children).forEach((route) => {
+            if (!isElementOfType(route, Route)) {
+                return;
+            }
+            const { name, element, ...page } = route.props;
+            resolved.push({ definition: { ...page, name: name ?? slug(page.path) }, element });
+        });
+    });
+    return resolved;
+}
+/** The `pages` member a resolved route set stands for, or `undefined` when there are none. */
+export function pagesFrom(routes) {
+    return routes.length ? routes.map((route) => route.definition) : undefined;
+}
+/**
+ * The `<section slot="page-…">` elements `gp-admin` renders custom pages into.
+ *
+ * A React-node `element` becomes the section's children. A builder is mounted
+ * through a ref: the section is created empty and the builder's node appended
+ * once, on attach. The ref deliberately rebuilds nothing on re-render — these
+ * pages own their own DOM and their own updates (ADR 0017), and re-running a
+ * builder under them would throw away the state they are holding.
+ */
+export function pageSectionsFrom(routes) {
+    return routes.map(({ definition, element }) => createElement('section', {
+        key: definition.name,
+        slot: `page-${definition.name}`,
+        ...(isBuilder(element) ? { ref: mountBuilder(element) } : {}),
+    }, isBuilder(element) ? undefined : element));
+}
+/** A ref callback that appends the builder's node once, the first time the host attaches. */
+export function mountBuilder(build) {
+    return (host) => {
+        if (host && !host.firstChild) {
+            host.appendChild(build());
+        }
+    };
+}
+/**
+ * A function `element` is a builder, not a React node.
+ *
+ * React elements are objects and strings are strings, so a function is never
+ * a valid `ReactNode` — there is no ambiguity to resolve here, which is why
+ * the two forms can share one prop without a discriminator.
+ */
+function isBuilder(element) {
+    return typeof element === 'function';
+}
+/** `'/reports/settlement'` → `'reports-settlement'`. */
+function slug(path) {
+    return path
+        .toLowerCase()
+        .replace(/[^a-z0-9]+/g, '-')
+        .replace(/^-+|-+$/g, '');
+}
+/** A React element whose `type` is exactly this marker function. */
+function isElementOfType(node, type) {
+    return typeof node === 'object' && node !== null && 'type' in node && node.type === type;
+}

package/dist/composition/index.d.ts

@@ -0,0 +1,55 @@
+/**
+ * The composition layer: a thin, additive JSX authoring surface over the
+ * existing config-as-data public API (ADR 0028). None of this is a new
+ * runtime — `Admin`/`Resource` are renamed pass-throughs to `gp-admin`/
+ * `gp-resource` (ADR 0012), and the rest are read once into the same
+ * `UdsAdminResource` shape a hand-written `config` object already produces.
+ *
+ * ## What mirrors react-admin, and what does not
+ *
+ * **Mirrors react-admin one-to-one** (https://marmelab.com/react-admin/Tutorial.html):
+ * `Admin`, `Resource`, `List`, `DataTable`, `DataTable.Col`, `Show`, `Edit`,
+ * `Create`, `SimpleForm` and its inputs, `TabbedShowLayout` /
+ * `TabbedShowLayout.Tab`, `ReferenceManyField`, `CustomRoutes` / `Route`.
+ *
+ * **Deliberate extensions beyond react-admin** (ADR 0030): `Board` and
+ * `CardGrid`. React-admin ships no kanban-board and no card-grid list view
+ * anywhere in its core — Marmelab's own Kanban is built from scratch in a
+ * tutorial and their Atomic CRM demo hand-rolls its deal pipeline. These
+ * exist because this library's pattern layer already ships both as
+ * `kind: 'board' | 'grid'` layouts (ADR 0016). They follow react-admin's
+ * grammar even so: they are *view children of `<List>`*, siblings of
+ * `<DataTable>`, never replacements for `<List>` itself.
+ *
+ * **Deliberately absent**: `Filter` — react-admin has no such tag, only a
+ * `filters` array *prop*, which `List.filters` mirrors directly. And no
+ * `Money`/`Status` tags, which react-admin likewise does not ship.
+ *
+ * **The two places this surface used to be narrower than react-admin are
+ * closed** (ADR 0031). `Show`/`Edit`/`Create` may carry genuinely different
+ * field sets — they are merged into the shell's one `fields` array and gated
+ * per mode via `UdsRecordField.modes` — and `ReferenceManyField` works both
+ * inside a view, reading the record's id from context as react-admin does,
+ * and as a child of `Resource` with an explicit `id`, which keeps working.
+ *
+ * What remains loud is only what one shell rendering one tab strip genuinely
+ * cannot express: wrappers that use different layouts, order the same fields
+ * differently, or name, order or label tabs differently. Those are rejected
+ * at read time with an error naming the limitation, never approximated — see
+ * `record.tsx`, `reference-many.tsx`, ADR 0030, ADR 0031 and
+ * `docs/specs/north-star-composition.md` §12 and §14.
+ */
+export { Admin } from './admin';
+export type { AdminProps } from './admin';
+export { Resource } from './resource';
+export type { ResourceProps } from './resource';
+export { List, DataTable, Board, CardGrid } from './list';
+export type { ListProps, ListViewActionProps, DataTableProps, DataTableColProps, BoardProps, CardGridProps, } from './list';
+export { Show, Edit, Create, TabbedShowLayout } from './record';
+export type { ShowProps, EditProps, CreateProps, TabbedShowLayoutProps, TabbedShowLayoutTabProps, } from './record';
+export { ReferenceManyField } from './reference-many';
+export type { ReferenceManyFieldProps } from './reference-many';
+export { CustomRoutes, Route } from './custom-routes';
+export type { CustomRoutesProps, RouteProps, UdsPageBuilder } from './custom-routes';
+export { SimpleForm, TextInput, NumberInput, BooleanInput, DateInput, SelectInput, ReferenceInput, } from './simple-form';
+export type { SimpleFormProps, TextInputProps, NumberInputProps, BooleanInputProps, DateInputProps, SelectInputProps, ReferenceInputProps, } from './simple-form';

package/dist/composition/index.js

@@ -0,0 +1,48 @@
+/**
+ * The composition layer: a thin, additive JSX authoring surface over the
+ * existing config-as-data public API (ADR 0028). None of this is a new
+ * runtime — `Admin`/`Resource` are renamed pass-throughs to `gp-admin`/
+ * `gp-resource` (ADR 0012), and the rest are read once into the same
+ * `UdsAdminResource` shape a hand-written `config` object already produces.
+ *
+ * ## What mirrors react-admin, and what does not
+ *
+ * **Mirrors react-admin one-to-one** (https://marmelab.com/react-admin/Tutorial.html):
+ * `Admin`, `Resource`, `List`, `DataTable`, `DataTable.Col`, `Show`, `Edit`,
+ * `Create`, `SimpleForm` and its inputs, `TabbedShowLayout` /
+ * `TabbedShowLayout.Tab`, `ReferenceManyField`, `CustomRoutes` / `Route`.
+ *
+ * **Deliberate extensions beyond react-admin** (ADR 0030): `Board` and
+ * `CardGrid`. React-admin ships no kanban-board and no card-grid list view
+ * anywhere in its core — Marmelab's own Kanban is built from scratch in a
+ * tutorial and their Atomic CRM demo hand-rolls its deal pipeline. These
+ * exist because this library's pattern layer already ships both as
+ * `kind: 'board' | 'grid'` layouts (ADR 0016). They follow react-admin's
+ * grammar even so: they are *view children of `<List>`*, siblings of
+ * `<DataTable>`, never replacements for `<List>` itself.
+ *
+ * **Deliberately absent**: `Filter` — react-admin has no such tag, only a
+ * `filters` array *prop*, which `List.filters` mirrors directly. And no
+ * `Money`/`Status` tags, which react-admin likewise does not ship.
+ *
+ * **The two places this surface used to be narrower than react-admin are
+ * closed** (ADR 0031). `Show`/`Edit`/`Create` may carry genuinely different
+ * field sets — they are merged into the shell's one `fields` array and gated
+ * per mode via `UdsRecordField.modes` — and `ReferenceManyField` works both
+ * inside a view, reading the record's id from context as react-admin does,
+ * and as a child of `Resource` with an explicit `id`, which keeps working.
+ *
+ * What remains loud is only what one shell rendering one tab strip genuinely
+ * cannot express: wrappers that use different layouts, order the same fields
+ * differently, or name, order or label tabs differently. Those are rejected
+ * at read time with an error naming the limitation, never approximated — see
+ * `record.tsx`, `reference-many.tsx`, ADR 0030, ADR 0031 and
+ * `docs/specs/north-star-composition.md` §12 and §14.
+ */
+export { Admin } from './admin';
+export { Resource } from './resource';
+export { List, DataTable, Board, CardGrid } from './list';
+export { Show, Edit, Create, TabbedShowLayout } from './record';
+export { ReferenceManyField } from './reference-many';
+export { CustomRoutes, Route } from './custom-routes';
+export { SimpleForm, TextInput, NumberInput, BooleanInput, DateInput, SelectInput, ReferenceInput, } from './simple-form';

package/dist/composition/list.d.ts

@@ -0,0 +1,220 @@
+import type { ReactNode } from 'react';
+import type { UdsAdminListConfig, UdsListAction, UdsListColumn, UdsListFilterField, UdsListLane, UdsListMedia } from '@globalpayments-private/gpds-pattern-web';
+/**
+ * `List`, `DataTable` and `DataTable.Col`: non-rendering marker components
+ * read by `Resource` (`resource.tsx`) to build a `UdsAdminListConfig` before
+ * anything reaches `gp-resource`/`gp-pattern-list`.
+ *
+ * ## Why these never render
+ *
+ * Every `@slot` this library ships holds markup rendered verbatim; none holds
+ * a schema read back out and discarded. `List`/`DataTable`/`DataTable.Col`
+ * are the one necessary exception ADR 0009 already accepts for
+ * `<Column>`/`<Filter>`-shaped authoring, so they stay here rather than
+ * becoming real elements: each one is called with its props and children at
+ * read time (`listConfigFromChildren`, below), and the resulting
+ * `UdsAdminListConfig` is handed to `<GpResource config>` — the same public
+ * prop a hand-written consumer uses (ADR 0012's equivalence rule). None of
+ * these functions is ever invoked by React; they only need a stable function
+ * identity so the reader below can recognise which element is which.
+ *
+ * ## Why the set mirrors what react-admin ships — and where it deliberately does not
+ *
+ * Per explicit direction, this composition layer duplicates real
+ * react-admin's shipped API (https://marmelab.com/react-admin/Tutorial.html)
+ * one-to-one rather than approximating it: `DataTable` is named after
+ * react-admin's actual table view component, and `DataTable.Col` after
+ * `DataTable.Col` — see `docs/specs/north-star-composition.md` §10 for the
+ * full reasoning. `Filter` is dropped entirely: react-admin has no such tag,
+ * only a `filters` array *prop* of input elements, which `List.filters`
+ * mirrors directly (`UdsListFilterField` is already the plain-object shape
+ * that prop wants, so there is nothing to translate).
+ *
+ * `Board` and `CardGrid` are the two **deliberate extensions beyond
+ * react-admin** (ADR 0030). React-admin ships no kanban-board and no
+ * card-grid list view anywhere in its core, under any name or shape:
+ * Marmelab's own Kanban is built from scratch in a tutorial
+ * (https://marmelab.com/blog/2023/07/28/create-a-kanban-board-in-react-admin.html)
+ * and their Atomic CRM demo hand-rolls its deal pipeline. They exist here
+ * because this library's pattern layer already ships both presentations as
+ * `kind: 'board' | 'grid'` layouts (ADR 0016) and the authoring surface was
+ * the only thing that could not reach them.
+ *
+ * They are shaped to react-admin's *grammar* even though the components are
+ * ours: in react-admin **the `<List>` element never swaps — only its view
+ * child does** (`<DataTable>`, `<SimpleList>`, `<SingleFieldList>`). So these
+ * are siblings of `DataTable` *inside* `<List>`, never replacements for
+ * `<List>` itself. A `<Board>` that replaced `<List>` would discard the
+ * querying, URL state, sorting, filtering, pagination and capability gating
+ * that `<List>` is, which is the whole claim of ADR 0016.
+ *
+ * All three view children read the same `<DataTable.Col>` children, because
+ * columns are the configuration for *every* layout — moving a list between
+ * presentations is one tag and never a rewrite of its columns.
+ *
+ * ## Where the actions live, and why the two differ
+ *
+ * `bulkActions` sits on the **view child, not on `<List>`**, because that is
+ * where real react-admin puts it: `bulkActionButtons` is a documented prop of
+ * `<DataTable>` (https://marmelab.com/react-admin/DataTable.html#props), not
+ * of `<List>`. Row *selection* is a property of the thing that renders rows,
+ * so the toolbar acting on a selection belongs beside it. Our config object
+ * happens to keep `bulkActions` under `list`, and that was not allowed to
+ * decide the JSX: the projection translates, exactly as `perPage` is a
+ * `<List>` prop that lands outside `list` (see `listConfigFromChildren`).
+ *
+ * `rowActions` sits there too, and that one **is a deviation**, stated rather
+ * than hidden. React-admin has no `rowActions` prop; it spells a row action
+ * as an ordinary button inside a column — `<DataTable.Col><EditButton /></…>`.
+ * That shape cannot be mirrored here for two independent reasons:
+ *
+ * 1. **Ours are effects, not elements.** `UdsListAction` is a description of
+ *    a write (`{ kind: 'update', values }`), executed by the pattern through
+ *    the staged, capability-gated, undoable path of ADR 0010 — and *not
+ *    rendered at all* when the adapter cannot service it (ADR 0002 §2). A
+ *    React element child is an instruction to render something regardless;
+ *    accepting one would mean either ignoring what it renders or losing the
+ *    gating, and both are worse than a different spelling.
+ * 2. **Two of the three layouts have no columns to put it in.** `board` and
+ *    `grid` render row actions in the card footer. A column-shaped spelling
+ *    would be correct for `table` and meaningless for the other two, which
+ *    breaks the one-tag-swap rule the view children exist to keep.
+ *
+ * So both are plain array props, for the same reason `filters` is one: the
+ * underlying member is already the plain-object shape the prop wants, and
+ * inventing a `<RowAction>` tag would add a vocabulary without adding a
+ * capability. See ADR 0032.
+ */
+/** A pure-data column: everything `DataTable.Col` accepts except the raw React element wrapper. */
+export interface DataTableColProps {
+    field: string;
+    label: string;
+    sortable?: boolean;
+    align?: UdsListColumn['align'];
+    width?: string;
+    /** `{ resource: 'merchants' }` shorthand — defaults `field` to `'name'`. */
+    reference?: string | UdsListColumn['reference'];
+    /**
+     * A column factory, called as `(field, label) => UdsListColumn` — the exact
+     * signature `moneyColumn`/`statusColumn` already export. Mirrors
+     * `<DataTable.Col source="email"><EmailField source="email" /></DataTable.Col>`:
+     * the child does the real work, the wrapper only carries `field`/`label`.
+     */
+    children?: (field: string, label: string) => UdsListColumn;
+}
+/** Marker component for one table column. Never rendered — see the module doc. */
+export declare function DataTableCol(_props: DataTableColProps): null;
+/**
+ * The two action props every view child accepts.
+ *
+ * Factored out rather than repeated three times because `rowActions` renders
+ * in a trailing column for `table` and in the card footer for `board` and
+ * `grid` — one configuration, three presentations, which is the same rule
+ * columns already follow. See the module doc for why these sit on the view
+ * child and not on `<List>`.
+ */
+export interface ListViewActionProps {
+    /**
+     * Actions offered on each record, forwarded to `UdsListConfig.rowActions`.
+     *
+     * **A deviation from react-admin**, deliberately — see the module doc. An
+     * action the adapter cannot service is absent rather than disabled, and
+     * `available` — an extension with no react-admin counterpart, like `Board`
+     * and `CardGrid` (ADR 0030) — hides one for records it does not apply to.
+     */
+    rowActions?: UdsListAction[];
+    /**
+     * Actions offered on the current selection, forwarded to
+     * `UdsListConfig.bulkActions`. Mirrors the placement of react-admin's
+     * `bulkActionButtons`, which is likewise a prop of the table view and not
+     * of `<List>`.
+     */
+    bulkActions?: UdsListAction[];
+}
+export interface DataTableProps extends ListViewActionProps {
+    children?: ReactNode;
+}
+/** Marker component for the table view. Never rendered. */
+export declare function DataTable(_props: DataTableProps): null;
+export declare namespace DataTable {
+    var Col: typeof DataTableCol;
+}
+/**
+ * **An extension beyond react-admin** (see the module doc): cards distributed
+ * into lanes by the value of one field — a pipeline rather than a ledger.
+ *
+ * The stacks are **lanes**, never "columns". `UdsListBoardLayout` spends a
+ * long comment on why the word is spent only once: this library ships a
+ * *column chooser*, and a user who opens a menu labelled "Columns" on a
+ * kanban and is shown field names has been misled by our vocabulary. The JSX
+ * honours the same rule — `groupBy` names the lane-forming field, exactly as
+ * the underlying layout member does, so the projection is one-to-one and
+ * there is no second vocabulary to keep in step.
+ */
+export interface BoardProps extends ListViewActionProps {
+    /** The field whose value forms the lanes. Mirrors `UdsListBoardLayout.groupBy`. */
+    groupBy: string;
+    /** The lanes to render, in order. Omit to derive them from the data. */
+    lanes?: UdsListLane[];
+    /** The column whose value heads each card, by `field`. Defaults to the first. */
+    title?: string;
+    /** Which columns fill the card body, by `field`. Defaults to every other one. */
+    fields?: string[];
+    /** The narrowest a lane may become, as a CSS length. */
+    minLaneWidth?: string;
+    /** `<DataTable.Col>` children — the same columns a table would read. */
+    children?: ReactNode;
+}
+/** Marker component for the board view. Never rendered — see the module doc. */
+export declare function Board(_props: BoardProps): null;
+/**
+ * **An extension beyond react-admin** (see the module doc): rows as a
+ * responsive grid of cards — a catalogue rather than a ledger.
+ *
+ * Named `CardGrid` rather than `Grid` because a bare `Grid` reads as a
+ * generic layout primitive (it is one, in every component library this sits
+ * beside) rather than as a list *view*, and this is only ever the latter.
+ */
+export interface CardGridProps extends ListViewActionProps {
+    /** The column whose value heads each card, by `field`. Defaults to the first. */
+    title?: string;
+    /** An image to lead each card with. Omit for text-only cards. */
+    media?: UdsListMedia;
+    /** Which columns fill the card body, by `field`. Defaults to every other one. */
+    fields?: string[];
+    /** The narrowest a card may become before the grid drops a column, as a CSS length. */
+    minColumnWidth?: string;
+    /** `<DataTable.Col>` children — the same columns a table would read. */
+    children?: ReactNode;
+}
+/** Marker component for the card-grid view. Never rendered — see the module doc. */
+export declare function CardGrid(_props: CardGridProps): null;
+export interface ListProps {
+    perPage?: number;
+    /**
+     * Passed straight through to `UdsAdminListConfig.filters` — a plain prop,
+     * not a child element, matching react-admin's own `<List filters={[...]}>`
+     * (see the module doc).
+     */
+    filters?: UdsListFilterField[];
+    /** The view child: `<DataTable>`, `<Board>` or `<CardGrid>`. */
+    children?: ReactNode;
+}
+/** Marker component for the list workflow. Never rendered — see the module doc. */
+export declare function List(_props: ListProps): null;
+/**
+ * Reads a `<List>` element's props and view child into a `UdsAdminListConfig`
+ * — the exact shape `GpResource`'s `config.list` takes (ADR 0022).
+ *
+ * `perPage` is a scalar, forwarded as `UdsAdminResource.perPage` rather than
+ * as a member of this config (see `admin-config.ts`'s `perPage` doc) — the
+ * caller (`resource.tsx`) is responsible for placing it there; this function
+ * only returns what belongs under `list`.
+ *
+ * The view child decides the `layout` and nothing else: all three read the
+ * same `<DataTable.Col>` children into the same `columns`, which is what
+ * makes swapping one for another a one-tag change (ADR 0016). A `<List>` with
+ * no recognised view child keeps the table default rather than rendering
+ * nothing, matching the behaviour before the board and grid views existed.
+ */
+export declare function listConfigFromChildren(listChildren: ReactNode): UdsAdminListConfig;