@wix/patterns 1.476.0 → 1.477.0

package/dist/docs/ImportButton.md

@@ -28,7 +28,7 @@ Like `ExportTo`, the feature has two parts:
 
 #### Configuring it
 
-`<ImportButton>` reads what it needs off the table's source when the modal opens; the optional `config` (`ImportConfig`) fills in what the source can't supply. Two things vary — **where the rows are written** (a Wix Data collection, or a platformized `destination`) and **where the mappable fields come from** (a declared schema source, or a `fields` list you pass) — giving three setups:
+`<ImportButton>` reads what it needs off the table's source when the modal opens; the optional `config` (`ImportConfig`) fills in what the source can't supply. Two setups, by **where the rows are written**:
 
 - **CMS (Wix Data) — schema-based, no `config`.** `useCmsSchemaSource` → `useTableCollection(source)`; the source supplies the collection, its fields, and create-new-field, and the CMS create/edit-field modal loads on demand. `<ImportButton />` takes no props.
 
@@ -37,18 +37,7 @@ Like `ExportTo`, the feature has two parts:
   <Table state={state} importButton={<ImportButton />} />;
   ```
 
-- **Platformized, from a source — schema-based, `config` names the destination.** A non–Wix-Data entity backed by `usePlatformizedSource`: the source supplies the fields to map onto, and you name the `destination` (a platformized target has no Wix Data collection to derive it from).
-
-  ```jsx
-  const source = usePlatformizedSource({ fqdn, backend, itemKey, itemName });
-  const state = useTableCollection(source);
-  <Table
-    state={state}
-    importButton={<ImportButton config={{ destination: { storesCatalogProducts: {} } }} />}
-  />;
-  ```
-
-- **Platformized, fields listed inline — non-schema, `config` names the destination and the fields.** No source; you list the `fields` to map onto (see `ProductsTable` in `example-bm`).
+- **Platformized — `config` names the destination and the fields.** No source; you list the `fields` to map onto (see `ProductsTable` in `example-bm`).
 
   ```jsx
   <Table
@@ -64,7 +53,7 @@ Like `ExportTo`, the feature has two parts:
   />;
   ```
 
-`ImportConfig`: `destination` (the platformized target; omit for CMS), `fields` (list to map onto; unneeded when a source supplies them), plus optional `backup`, `idFieldKey`, and `jobApplicationErrorMap` — see the examples below. **Create-new-field is a CMS (Wix Data) capability**; platformized imports map onto existing fields only.
+`ImportConfig`: `destination` (the platformized target; omit for CMS), `fields` (list to map onto; unneeded for CMS, where the source supplies them), plus optional `backup`, `idFieldKey`, and `jobApplicationErrorMap` — see the examples below. **Create-new-field is a CMS (Wix Data) capability**; platformized imports map onto existing fields only.
 
 #### data-hub infrastructure
 
@@ -96,19 +85,11 @@ Example code: read `dist/examples/ImportButton/cms-import.tsx`
 
 ---
 
-### Platformized import (fields inline)
+### Platformized import
 
 A non–Wix-Data destination (here the stores catalog) with no declared schema: pass a `config` naming the `destination` and listing the `fields` to map onto.
 
-Example code: read `dist/examples/ImportButton/platformized-import-fields-inline.tsx`
-
----
-
-### Platformized import (from a source)
-
-A non–Wix-Data destination whose fields come from a source (`usePlatformizedSource`) instead of an inline list — like the CMS case, but you still name the `destination` in `config`.
-
-Example code: read `dist/examples/ImportButton/platformized-import-from-a-source.tsx`
+Example code: read `dist/examples/ImportButton/platformized-import.tsx`
 
 ---
 

package/dist/docs/Reading the Doc Indices.md

@@ -30,6 +30,7 @@ undocumented — look it up in the docs index.
 | `symbols` | export names that resolve to this entry, where the doc's title is not the export |
 | `examples` | worked examples for this name, relative to `dist/examples/` |
 | `relatedComponents` | on a guide: the components it recommends |
+| `variants` | the same name exported from another entry point with a different declaration — see below |
 | `status`, `statusMessage` | see *Lifecycle*, below |
 
 **The three fields above answer three different questions, and one entry rarely needs all
@@ -50,6 +51,26 @@ disagree.
 documents `ExportButton`; `ToolbarFilters` is the entry for `CollectionToolbarFilters`. That
 is what `symbols` is for — resolve a name against the keys *and* the aliases.
 
+**One name can have more than one declaration.** `Table`, `Grid`, `EntityPage`,
+`useCollection`, `useTableCollection`, `useGridCollection` and `useEntityPage` are exported
+from both `@wix/patterns` and `@wix/patterns/schema`, and the schema versions take a source
+as their first argument. The entry under the name is the root version. `variants` lists the
+others, each with its `importPath`, its declaration (`bundle` in the docs index, `file` in the
+bundle index) and the page that documents it (`doc`). In `dist/dts-bundle/index.txt` each
+variant is a line of its own, so a grep for the name returns every version. Choose by
+`importPath`, and take the hook and the component from the same entry point.
+`EditableTable`, `LayoutSwitch` and their hooks are curated only in their schema versions, so
+their entries are those versions.
+
+**A name can come from another package.** `useCmsSchemaSource`, `UseCmsSchemaSourceDeps`,
+`listCmsCollections` and `CmsCollectionSummary` are `@wix/patterns-cms` exports, in the bundle
+index because a CMS page needs them. Their entries carry `package` and
+`importPath: "@wix/patterns-cms"`, and `packageVersion`: the `@wix/patterns-cms` release that
+depends on exactly this `@wix/patterns` version. Install that one. A release that pins another
+`@wix/patterns` version installs a second copy of it, and the page ends up split across two
+React contexts, which neither `tsc` nor a build reports. An entry's `doc` names the page that
+documents a name with no page of its own.
+
 **Where a name's props live is stated, not guessed.** An entry with a `bundle` field has no
 props table in its doc: its `### Props` section points at that bundle on purpose, and the
 bundle is the better source because it keeps the `extends` clause with its exclusions. An

package/dist/docs/index.json

@@ -222,7 +222,7 @@
   "CustomFieldType": {
     "file": "CustomFieldType.md",
     "category": "Features/Enrich/Custom Field Types",
-    "summary": "A **custom field type** is a consumer-defined field that plugs into every schema-driven surface. Define it once with `defineFieldType<V>()` and register it on the schema source via `fieldTypes` — the page wires nothing per surface. Each surface resolves its own slot from the definition:",
+    "summary": "A **custom field type** is a consumer-defined field that plugs into every schema-driven surface. Define it once with `defineFieldType<V>()` and register it on `useCmsSchemaSource` via `fieldTypes` — the page wires nothing per surface. Each surface resolves its own slot from the definition:",
     "examples": [
       "CustomFieldType/table-cell-and-filter.tsx",
       "CustomFieldType/editable-cell.tsx",
@@ -302,6 +302,13 @@
     "category": "Base Components/Pages/Entity Page",
     "summary": "The `EntityPage` component serves as a container that encapsulates the logic and layout structure for rendering an entity page. It provides a structured and organized way to display and manage information related to a specific entity.",
     "importPath": "@wix/patterns",
+    "variants": [
+      {
+        "importPath": "@wix/patterns/schema",
+        "bundle": "components/schema/EntityPage.d.ts",
+        "doc": "useSchemaSource.md"
+      }
+    ],
     "bundle": "components/EntityPage.d.ts",
     "propsTotal": 15,
     "propsTypeName": "EntityPageProps",
@@ -399,6 +406,13 @@
     "category": "Base Components/Collections/Grid/Grid",
     "summary": "The `Grid` component displays cards in rows and columns as an alternative to tables. It is responsive, adjusting the number of cards per row based on the viewport width, and includes built-in virtualization for efficient rendering of many items without impacting performance.",
     "importPath": "@wix/patterns",
+    "variants": [
+      {
+        "importPath": "@wix/patterns/schema",
+        "bundle": "components/schema/Grid.d.ts",
+        "doc": "useSchemaSource.md"
+      }
+    ],
     "bundle": "components/Grid.d.ts",
     "propsTotal": 39,
     "propsTypeName": "GridProps",
@@ -479,6 +493,7 @@
     "summary": "A collection page and the form for one of its items are **two patterns pages**, not a page plus a modal. That holds for creating a record as much as editing one: an \"add new\" form writes the record, so it is an `EntityPage` however small it is.",
     "relatedComponents": [
       "CollectionPage",
+      "useSchemaSource",
       "EntityPage",
       "EntityPageState",
       "useEntityPage",
@@ -495,6 +510,7 @@
     "summary": "Which component to reach for, arranged by what the person using the dashboard is trying to do: understand the situation, narrow it, open one record, act, and be told what happened.",
     "relatedComponents": [
       "SummaryBar",
+      "useSchemaSource",
       "CollectionSearch",
       "CollectionToolbarFilters",
       "MultiSelectCheckboxFilter",
@@ -546,6 +562,7 @@
     "summary": "Every patterns page is four nested layers. Getting the nesting wrong is the most common way a page that looks right throws at runtime.",
     "relatedComponents": [
       "WixPatternsProvider",
+      "useSchemaSource",
       "WixPatternsBMProvider",
       "WixPatternsGizaProvider",
       "WixPatternsEssentialsProvider",
@@ -604,8 +621,7 @@
     "importPath": "@wix/patterns",
     "examples": [
       "ImportButton/cms-import.tsx",
-      "ImportButton/platformized-import-fields-inline.tsx",
-      "ImportButton/platformized-import-from-a-source.tsx",
+      "ImportButton/platformized-import.tsx",
       "ImportButton/required-fields.tsx",
       "ImportButton/create-new-field.tsx",
       "ImportButton/update-or-skip-by-id.tsx",
@@ -895,12 +911,17 @@
   "useSchemaSource": {
     "file": "useSchemaSource.md",
     "category": "Base Components/Schema Source",
-    "summary": "A **schema source** describes a collection once: its fields, how to read and write its items, and, optionally, how to add, edit and delete fields. The `@wix/patterns/schema` entry builds the page from it. Columns, filters, grid cards, entity-page forms and field management all come from the source, so you don't list them by hand.",
+    "summary": "The `@wix/patterns/schema` entry builds a page from a **Wix Data (CMS) collection**. Its source, `useCmsSchemaSource` from `@wix/patterns-cms`, describes the collection once: its fields, how to read and write its items, and how to add, edit and delete fields. Columns, filters, grid cards, entity-page forms and field management all come from the source, so you don't list them by hand.",
     "importPath": "@wix/patterns/schema",
+    "bundle": "hooks/useSchemaSource.d.ts",
+    "propsTotal": 16,
+    "propsTypeName": "SchemaSourceInput",
+    "symbols": [
+      "EntityPageFieldsCard"
+    ],
     "examples": [
       "useSchemaSource/cms-collection.tsx",
-      "useSchemaSource/extra-columns-and-data.tsx",
-      "useSchemaSource/your-own-source.tsx"
+      "useSchemaSource/extra-columns-and-data.tsx"
     ]
   },
   "SecondaryActions": {
@@ -1023,6 +1044,13 @@
     "category": "Base Components/Collections/Table/Table",
     "summary": "The `Table` component displays data in rows and columns, allowing you to organize information in an easy-to-scan format. This component extends the standard Wix Design System `Table` to offer additional advanced features like infinite scroll, search, and filters.",
     "importPath": "@wix/patterns",
+    "variants": [
+      {
+        "importPath": "@wix/patterns/schema",
+        "bundle": "components/schema/Table.d.ts",
+        "doc": "useSchemaSource.md"
+      }
+    ],
     "bundle": "components/Table.d.ts",
     "propsTotal": 63,
     "propsTypeName": "TableProps",
@@ -1374,6 +1402,13 @@
     "category": "Common/Hooks",
     "summary": "The base React hook for creating a `CollectionState`. All other collection hooks (`useTableCollection`, `useGridCollection`, etc.) build on top of `useCollection`. Use this hook directly when you need a collection state that is not tied to a specific component, or when building custom collection components.",
     "importPath": "@wix/patterns",
+    "variants": [
+      {
+        "importPath": "@wix/patterns/schema",
+        "bundle": "hooks/schema/useCollection.d.ts",
+        "doc": "useSchemaSource.md"
+      }
+    ],
     "bundle": "hooks/useCollection.d.ts",
     "propsTotal": 17,
     "propsTypeName": "CollectionConfig"
@@ -1405,6 +1440,13 @@
     "category": "Base Components/Pages/Entity Page/Hooks/useEntityPage",
     "summary": "A React hook that creates the state for an `EntityPage`. Configure entity fetching, save flow, form integration, toasts, and navigation. The returned `EntityPageState` is passed to `<EntityPage state={state}>`.",
     "importPath": "@wix/patterns",
+    "variants": [
+      {
+        "importPath": "@wix/patterns/schema",
+        "bundle": "hooks/schema/useEntityPage.d.ts",
+        "doc": "useSchemaSource.md"
+      }
+    ],
     "bundle": "hooks/useEntityPage.d.ts",
     "propsTotal": 11,
     "propsTypeName": "UseEntityPageParams"
@@ -1430,6 +1472,13 @@
     "category": "Base Components/Collections/Grid/useGridCollection",
     "summary": "`useGridCollection` is a React hook designed to facilitate the management of the `Grid` component.It returns a `GridState` to pass to the `state` prop of the `Grid` component.",
     "importPath": "@wix/patterns",
+    "variants": [
+      {
+        "importPath": "@wix/patterns/schema",
+        "bundle": "hooks/schema/useGridCollection.d.ts",
+        "doc": "useSchemaSource.md"
+      }
+    ],
     "bundle": "hooks/useGridCollection.d.ts",
     "propsTotal": 17,
     "propsTypeName": "CollectionConfig"
@@ -1525,6 +1574,13 @@
     "category": "Base Components/Collections/Table/useTableCollection",
     "summary": "`useTableCollection` is a React hook designed to facilitate the management of the `Table` component.It returns a `TableState` to pass to the `state` prop of the `Table` component.",
     "importPath": "@wix/patterns",
+    "variants": [
+      {
+        "importPath": "@wix/patterns/schema",
+        "bundle": "hooks/schema/useTableCollection.d.ts",
+        "doc": "useSchemaSource.md"
+      }
+    ],
     "bundle": "hooks/useTableCollection.d.ts",
     "propsTotal": 17,
     "propsTypeName": "CollectionConfig"

package/dist/docs/useSchemaSource.md

@@ -12,82 +12,44 @@ Some of that scaffolding is environment-scoped and is **not** needed to use this
 
 ### Description
 
-A **schema source** describes a collection once: its fields, how to read and write its items, and, optionally, how to add, edit and delete fields. The `@wix/patterns/schema` entry builds the page from it. Columns, filters, grid cards, entity-page forms and field management all come from the source, so you don't list them by hand.
+The `@wix/patterns/schema` entry builds a page from a **Wix Data (CMS) collection**. Its source, `useCmsSchemaSource` from `@wix/patterns-cms`, describes the collection once: its fields, how to read and write its items, and how to add, edit and delete fields. Columns, filters, grid cards, entity-page forms and field management all come from the source, so you don't list them by hand.
 
-Every page follows the same three steps:
+**For any other data, don't use this entry or `@wix/patterns-cms`.** Use the `@wix/patterns` hooks (`useTableCollection` and the rest) with your own `fetchData` and `columns`.
 
-1. **Create a source** for the collection.
+Every CMS page follows the same three steps:
+
+1. **Create the source** with `useCmsSchemaSource`.
 2. **Pass it to a collection hook** — `useTableCollection(source)`, `useGridCollection(source)`, `useEditableTableCollection(source)`, `useLayoutSwitchCollection(source, …)`, or `useEntityPage(source, …)` for a single item.
 3. **Render the state** with the component of the same name from `@wix/patterns/schema` — `Table`, `Grid`, `EditableTable`, `LayoutSwitch`, `EntityPage` (with `EntityPageFieldsCard` for the fields).
 
 ```ts
-import {
-  useSchemaSource,
-  useTableCollection,
-  Table,
-} from '@wix/patterns/schema';
-
-const source = useSchemaSource<Task>({
-  collectionId: 'tasks',
-  loadSchema: loadTasksSchema,
-});
-const state = useTableCollection<Task>(source);
+import { useTableCollection, Table } from '@wix/patterns/schema';
+import { useCmsSchemaSource } from '@wix/patterns-cms';
+
+const source = useCmsSchemaSource<Item>({ collectionId: 'Products' });
+const state = useTableCollection<Item>(source);
 
 <Table state={state} />;
 ```
 
 Take the component from `@wix/patterns/schema`, not from `@wix/patterns`. Fields such as dates, media and references render components that need the source in React context, and only the schema-entry components provide it.
 
-#### Choosing a source
-
-- **A Wix Data (CMS) collection — `useCmsSchemaSource`** from `@wix/patterns-cms`. Loads the collection's fields and items, and brings the CMS add/edit field modal. The field changes (the "+" header button, edit, delete) need the user's permissions: pass `includeUserPermissions: true` and the site's `metasiteId`. Without them, fields can't be changed.
-
-  ```ts
-  import { useCmsSchemaSource } from '@wix/patterns-cms';
-
-  const source = useCmsSchemaSource<Item>({ collectionId: 'Products' });
-  ```
-
-- **A platformized entity — `usePlatformizedSource`**. You keep your own item access (`backend.find`, plus optional writes). The source lets users add fields on top of your entity. Your entity's own fields are not part of it, so you still write their columns.
-
-  ```ts
-  import { usePlatformizedSource } from '@wix/patterns/schema';
+#### The source
 
-  const source = usePlatformizedSource<Product>({
-    fqdn: 'stores.catalog.product',
-    backend: { find: queryProducts },
-  });
-  ```
+`useCmsSchemaSource` loads the collection's fields, items and permissions, wires reference fields to the collections they point at, and brings the add/edit field modal with the types Wix Data can create. Don't write your own source for a CMS collection: you would lose all of that.
 
-- **Any other data — `useSchemaSource`**. You write `loadSchema`, which returns the fields (`schema`), the item access (`backend`), and optionally the field changes (`fieldActions`). This is also where you register custom field types (`fieldTypes`) and set up the add-field modal (`fieldModal`).
-
-  ```ts
-  import { useSchemaSource } from '@wix/patterns/schema';
-
-  const source = useSchemaSource<Task>({
-    collectionId: 'tasks',
-    loadSchema: async () => ({
-      schema: tasksSchema,
-      backend: tasksBackend,
-      fieldActions: tasksFieldActions,
-    }),
-  });
-  ```
+- **Field changes** (the "+" header button, edit, delete) need the user's permissions: pass `includeUserPermissions: true`. They are loaded for the site the patterns container runs in (`environment.msid`); pass `metasiteId` only to load them for another site. Without them, fields can't be changed.
+- **Custom field types** are registered with `fieldTypes` — see **Custom Field Types**.
+- **Install** `@wix/patterns-cms` at the version that depends on your exact `@wix/patterns` version. Any other version installs a second copy of `@wix/patterns`, and the page splits across two React contexts, which neither `tsc` nor a build reports.
 
 A source is created once per `collectionId`. Changing its other options on a later render has no effect. To switch collections, render the page again with a React `key` that includes the new id.
 
-#### What `loadSchema` returns
-
-- `schema` (`Schema`) — the fields keyed by id, plus `idField`, `displayField`, and `schemaPermissions` (which field changes the user may make). Without `schemaPermissions`, the fields can't be edited.
-- `backend` (`CollectionBackend`) — `find` is required. It receives the query's `search`, `filters`, `sort` and paging, and must apply all of them. A control that the backend ignores will show but do nothing. `get`, `create`, `update`, `delete`, `bulkDelete` and `bulkInsert` are optional. Each one you provide turns on the matching UI (for example, row edits in `EditableTable`).
-- `fieldActions` (`FieldActions`) — optional. `addField`, `editField`, `deleteField` and the other field changes. Each one except `renameField` returns the collection's updated fields, and the page applies them without loading the schema again. `renameField` returns nothing.
-
 #### Compared with the classic hooks
 
 |                                    | Classic (`@wix/patterns`)              | Schema (`@wix/patterns/schema`)                                                                                        |
 | ---------------------------------- | -------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
-| Data                               | `fetchData` on the hook options        | the source's `backend.find`                                                                                            |
-| `queryName`, `itemKey`, `itemName` | required on the hook                   | from the source (`collectionId`, `idField`, `displayField`)                                                            |
+| Data                               | `fetchData` on the hook options        | the collection, through `useCmsSchemaSource`                                                                           |
+| `queryName`, `itemKey`, `itemName` | required on the hook                   | from the source (the collection id, `_id`, the display field)                                                          |
 | Table columns                      | `columns` required                     | from the fields. `columns` is optional: its columns come first, and one with a field's id replaces that field's column |
 | Changing the fetch                 | replace `fetchData`                    | `wrapFetchData(next)` wraps the source's fetch                                                                         |
 | Field management                   | `fieldsSource` / `dataExtension` props | always on, from the source                                                                                             |
@@ -99,12 +61,13 @@ A source is created once per `collectionId`. Changing its other options on a lat
 
 
 ```tsx
-import { useSchemaSource, useTableCollection, Table } from '@wix/patterns/schema';
+import { useTableCollection, Table } from '@wix/patterns/schema';
+import { useCmsSchemaSource } from '@wix/patterns-cms';
 ```
 
 ### CMS collection
 
-What you get: a table over a Wix Data collection with no columns written by hand. `useCmsSchemaSource` loads the fields and the items. Every field becomes a column with its type icon, and the "+" header button adds a field once user permissions are loaded (`includeUserPermissions` and `metasiteId`). (In these docs `useCmsSchemaSource` uses in-memory data so it runs with no backend.)
+What you get: a table over a Wix Data collection with no columns written by hand. `useCmsSchemaSource` loads the fields and the items. Every field becomes a column with its type icon, and the "+" header button adds a field once user permissions are loaded (`includeUserPermissions: true`). (In these docs `useCmsSchemaSource` uses in-memory data so it runs with no backend.)
 
 Example code: read `dist/examples/useSchemaSource/cms-collection.tsx`
 
@@ -114,36 +77,13 @@ What you get: the columns from the fields, plus one you add. `columns` adds colu
 
 Example code: read `dist/examples/useSchemaSource/extra-columns-and-data.tsx`
 
-### Your own source
-
-What you get: a source over any data. `loadSchema` returns the fields (`schema`), the item access (`backend`), and optionally the field changes (`fieldActions`). `find` receives search, filters and sort and must apply them. Try it: search, sort by a column, or add a field with the "+" header button. The new field is stored in memory, so it resets on refresh.
-
-Example code: read `dist/examples/useSchemaSource/your-own-source.tsx`
-
 ## API
 
 ### Overview
 
-Options of `useSchemaSource` (`SchemaSourceInput<T>`). Only `collectionId` and `loadSchema` are required.
+Options of `useSchemaSource`, which `useCmsSchemaSource` builds on. A CMS page passes `useCmsSchemaSource` its own options (`collectionId`, `includeUserPermissions`, `metasiteId`, `fieldTypes`, …) instead — see `UseCmsSchemaSourceDeps` in the type index.
 
 ### Props
 
-| Prop | Type | Required | Default | Description |
-|------|------|----------|---------|-------------|
-| `references` | `Record<string, SchemaSource<any>>` | No | - | Sources for collections this one references, keyed by the referenced collection id. A renderer resolves a reference field through the matching entry — its `loadSchema` gives the referenced schema and `sourceFetchData` queries the referenced items. Default: none. |
-| `getReferencedCollectionSource` | `((collectionId: string) => SchemaSource<any>)` | No | - | Lazy source lookup for a referenced collection that is not in `references`. Is used when a reference field is created in the add field modal. The returned source owns its own async schema/item loading. |
-| `itemKey` | `((item: T) => string)` | No | - | Stable row identity. Default: `row[idField]`. |
-| `itemName` | `((item: T) => string)` | No | - | Row display label. Default: `row[displayField]`. |
-| `searchableFieldIds` | `((schema: Schema) => string[])` | No | - | Fields free-text search runs against. Default: `[displayField]`. |
-| `fieldModal` | `FieldModalInput` | No | - | What the add/edit field modal shows. Default: no types, generic titles. |
-| `fieldTypes` | `FieldTypeDefinition<unknown>[]` | No | - | Consumer-defined field types: how a field of that type renders, filters and validates wherever it appears. A field with `type: 'CUSTOM'` resolves its definition here by `customType`. The add/edit field modal never reads this — see `fieldModal`. Default: none. |
-| `getFieldPresentation` | `((field: Field) => FieldPresentation)` | No | - | Overrides one existing field's type label, icons and collection-picker label. Does not change its type, values or add-field options. |
-| `canAddFields` | `((schema: Schema) => boolean)` | No | - | Default: `schemaPermissions.createField`. |
-| `canEditField` | `((field: Field, schema: Schema) => boolean)` | No | - | Default: `schemaPermissions.updateField`, except for system fields and the id field. |
-| `canDeleteField` | `((field: Field, schema: Schema) => boolean)` | No | - | Default: `schemaPermissions.deleteField`, except for system fields and the id field. |
-| `getDeleteFieldConfirmation` | `((field: Field, schema: Schema) => DeleteFieldConfirmation)` | No | - | Resolved when deletion is requested. Undefined keeps the default dialog. |
-| `fieldPermissions` | `FieldPermissions` | No | - | Permission defaults shown in the modal. Absent ⇒ no permissions section. |
-| `supportsPii` | `boolean` | No | - | Default: `false`. |
-| `getFieldValue` | `((item: T, field: Field) => unknown)` | No | - | The value of a field on an item. Default: `item[field.id]`. |
-| `setFieldValue` | `((item: T, field: Field, value: unknown) => T)` | No | - | Writes a field's value on an item, returning the updated item. Default: `{ ...item, [field.id]: value }`. |
+Read `dist/dts-bundle/hooks/useSchemaSource.d.ts` for `useSchemaSource`'s props. Shared shapes cut to a one-line stub there hold 16 of them: `dist/dts-bundle/types/SchemaSourceInput.d.ts` (16).