@wix/patterns 1.427.0 → 1.431.0

package/dist/docs/ImportButton.md

@@ -17,38 +17,38 @@ It renders an import action in the collection toolbar. On the default toolbar it
 
 Like `ExportTo`, the feature has two parts:
 
-- **Client** — the button and modal, shipped in `@wix/patterns`. You configure it with a single `config` object plus a `renderFieldEditor`, both produced by a **source hook** (below), and place it with the `` `importButton` prop.
+- **Client** — the button and modal, shipped in `@wix/patterns`. Place it with the `` `importButton` prop; it reads what it needs off the table's source when the modal opens, and an optional `config` object carries only what the source can't supply (see [Choosing a source](#choosing-a-source)).
 - **Server** — the actual write is done by a Wix Hub **Data Movement** job (see the [data-hub infrastructure](#data-hub-infrastructure) section). The client uploads the file, submits the job, and polls it to completion.
 
-#### Choosing a source hook
+#### Configuring it
 
-`ImportButton` never takes hand-built inputs. You pick the hook that matches where the data is written, and spread its result onto ``:
+`` 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:
 
-- **CMS (Wix Data)** — [`useSchemaImport`](./?path=/story/features-import--use-schema-import). Reads the import inputs live from the same schema source that backs the table, and supplies the CMS create/edit-field modal.
+- **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. `` takes no props.
 
   ```jsx
-  import { ImportButton, useSchemaImport } from '@wix/patterns';
-
-  const importProps = useSchemaImport(schemaSource);
-
+  // `state` comes from `useTableCollection(source)` (@wix/patterns/schema).
   } />;
   ```
 
-- **Platformized (non–Wix-Data destination)** — [`usePlatformizedImport`](./?path=/story/features-import--use-platformized-import). For a target such as the stores catalog. Reads the table's toolbar so a DataExtension source's live fields are wired in.
+- **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
-  import { ImportButton, usePlatformizedImport } from '@wix/patterns';
+  const source = usePlatformizedSource({ fqdn, backend, itemKey, itemName });
+  const state = useTableCollection(source);
+  }
+  />;
+  ```
 
-  const importProps = usePlatformizedImport({
-    state,
-    destination: { storesCatalogProducts: {} },
-    fields: [{ id: 'name', header: 'Name', required: true }],
-  });
+- **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`).
 
-  } />;
+  ```jsx
+  
+    }
+  />;
   ```
 
-See each hook's page for its full props.
+`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.
 
 #### data-hub infrastructure
 
@@ -57,15 +57,15 @@ The import runs **entirely server-side** in [Wix Data Hub](https://github.com/wi
 1. Reserves an upload URL and PUTs the (rewritten) CSV, receiving a `fileId`.
 2. Submits a job (`source: { file }`, `destination`) and receives a `jobId`.
 3. Polls the job every 2 seconds until it reaches `COMPLETED`, `PARTIALLY_SUCCESSFUL`, or `FAILED`.
-4. Lists the job's per-row movement logs to build the failed-rows CSV, and terminates the job if the user cancels. Terminating does **not** roll back rows already written — that is what an optional `backup` (on either hook) is for.
+4. Lists the job's per-row movement logs to build the failed-rows CSV, and terminates the job if the user cancels. Terminating does **not** roll back rows already written — that is what an optional `backup` (in the `config`) is for.
 
-The **`destination`** you pass identifies which executor [destination](https://github.com/wix-private/wix-data-hub/blob/master/packages/wix-data-hub-executor-c/src/api/destination.ts) writes the rows — e.g. `{ wixDataCollection: … }` ([wix-data-collection](https://github.com/wix-private/wix-data-hub/tree/master/packages/wix-data-hub-executor-c/src/plugins/wix-data-collection) plugin) or `{ storesCatalogProducts: {} }` ([online-stores](https://github.com/wix-private/wix-data-hub/tree/master/packages/wix-data-hub-executor-c/src/plugins/online-stores) plugin). The CMS hook (`useSchemaImport`) builds the `wixDataCollection` destination for you; a platformized hook passes its `destination` through verbatim.
+The **`destination`** you pass identifies which executor [destination](https://github.com/wix-private/wix-data-hub/blob/master/packages/wix-data-hub-executor-c/src/api/destination.ts) writes the rows — e.g. `{ wixDataCollection: … }` ([wix-data-collection](https://github.com/wix-private/wix-data-hub/tree/master/packages/wix-data-hub-executor-c/src/plugins/wix-data-collection) plugin) or `{ storesCatalogProducts: {} }` ([online-stores](https://github.com/wix-private/wix-data-hub/tree/master/packages/wix-data-hub-executor-c/src/plugins/online-stores) plugin). The CMS case builds the `wixDataCollection` destination for you; a platformized `config` passes its `destination` through verbatim.
 
-Because a failed import comes back on a `200` (the failure is in the job status, not an HTTP error), the optional `jobApplicationErrorMap` (on either hook) lets you map the job's application-error codes to messages. You supply only the code → message map; the import resolves it through the error handler internally.
+Because a failed import comes back on a `200` (the failure is in the job status, not an HTTP error), the optional `jobApplicationErrorMap` (in the `config`) lets you map the job's application-error codes to messages. You supply only the code → message map; the import resolves it through the error handler internally.
 
 
 ```tsx
-import { ImportButton, useSchemaImport, usePlatformizedImport } from '@wix/patterns';
+import { ImportButton } from '@wix/patterns';
 ```
 
 ---
@@ -74,20 +74,14 @@ import { ImportButton, useSchemaImport, usePlatformizedImport } from '@wix/patte
 
 ### CMS import
 
-A Wix Data (CMS) collection. `useSchemaImport` reads the import inputs live from the table’s schema source and supplies the CMS create/edit-field modal; spread its result onto ``.
+A Wix Data (CMS) collection. `` needs no config — it reads the import inputs live from the table’s schema source, and the CMS create/edit-field modal is loaded on demand.
 
 ```tsx
 import React from 'react';
 import { CollectionPage } from '@wix/patterns/page';
-import {
-  CustomColumns,
-  ImportButton,
-  Table,
-  tableSchemaSource,
-  useSchemaImport,
-  useTableCollection,
-} from '@wix/patterns';
-import { createInMemorySchemaSource } from '@wix/patterns/testkit';
+import { CustomColumns, ImportButton, Table } from '@wix/patterns';
+import { useTableCollection } from '@wix/patterns/schema';
+import { useCmsSchemaSource } from '@wix/patterns-cms';
 
 type CmsItem = {
   _id: string;
@@ -96,30 +90,13 @@ type CmsItem = {
 };
 
 function CmsImport() {
-  // In a real app, build the source with `createCmsSchemaSource` from
-  // `@wix/patterns-cms`. This docs example uses an in-memory source so it runs
-  // with no backend — the wiring below is identical either way.
-  const [schemaSource] = React.useState(() => {
-    const { source } = createInMemorySchemaSource<CmsItem>({
-      collectionId: 'Products',
-      fields: [
-        { id: 'name', displayName: 'Name', type: 'SHORT_TEXT' },
-        { id: 'price', displayName: 'Price', type: 'NUMBER' },
-      ],
-      items: [
-        { _id: '1', name: 'Coffee Mug', price: '12' },
-        { _id: '2', name: 'T-Shirt', price: '25' },
-      ],
-    });
-    return tableSchemaSource(source);
-  });
-
-  const state = useTableCollection<CmsItem>(schemaSource.collectionConfig);
-
-  // `useSchemaImport` reads the import inputs (fields, collection, create-new-
-  // field, backup) live from the schema source and returns the `ImportButton`
-  // props — `config` + the CMS create/edit-field modal — so just spread them.
-  const importProps = useSchemaImport(schemaSource);
+  // The CMS (Wix Data) schema source: `useTableCollection` derives the query and
+  // identity from it and attaches its fields + field management to the table, so
+  // `<ImportButton />` reads everything it needs off the table when it opens — no
+  // config. (In these docs `useCmsSchemaSource` is backed by in-memory data so it
+  // runs with no backend.)
+  const source = useCmsSchemaSource<CmsItem>({ collectionId: 'Products' });
+  const state = useTableCollection<CmsItem>(source);
 
   return (
     <CollectionPage>
@@ -128,10 +105,9 @@ function CmsImport() {
         <Table
           state={state}
           horizontalScroll
-          fieldsSource={schemaSource}
           customColumns={<CustomColumns />}
           columns={[]}
-          importButton={<ImportButton {...importProps} />}
+          importButton={<ImportButton />}
         />
       </CollectionPage.Content>
     </CollectionPage>
@@ -143,9 +119,9 @@ export default CmsImport;
 
 ---
 
-### Platformized import
+### Platformized import (fields inline)
 
-A non–Wix-Data destination (here the stores catalog). `usePlatformizedImport` builds the config from the table’s toolbar + your `fields`/`destination`; spread its result onto ``.
+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.
 
 ```tsx
 import { Page } from '@wix/design-system';
@@ -155,8 +131,8 @@ import {
   PageWrapper,
   Table,
   ToolbarTitle,
-  usePlatformizedImport,
   useTableCollection,
+  type ImportConfig,
 } from '@wix/patterns';
 import { queryStoreVariants } from '@wix/ambassador-stores-catalog-v1-product/http';
 import { StoreVariant } from '@wix/ambassador-stores-catalog-v1-product/types';
@@ -181,17 +157,16 @@ function PlatformizedImport() {
     fetchErrorMessage: () => 'Error fetching products',
   });
 
-  // `usePlatformizedImport` reads the table's toolbar and returns the
-  // `ImportButton` props for a platformized (non–Wix-Data) destination — here
-  // the stores catalog. Spread the result.
-  const importProps = usePlatformizedImport({
-    state,
+  // A platformized (non–Wix-Data) destination — here the stores catalog — has no
+  // declared schema, so the `config` names the write target and lists the fields
+  // to map onto (plus any live fields the table's source exposes).
+  const importConfig: ImportConfig = {
     destination: { storesCatalogProducts: {} },
     fields: [
       { id: 'name', header: 'Name' },
       { id: 'sku', header: 'SKU' },
     ],
-  });
+  };
 
   return (
     <PageWrapper>
@@ -205,7 +180,7 @@ function PlatformizedImport() {
             columns={[
               { title: 'Name', render: (variant) => variant.productName },
             ]}
-            importButton={<ImportButton {...importProps} />}
+            importButton={<ImportButton config={importConfig} />}
           />
         </Page.Content>
       </Page>
@@ -218,9 +193,68 @@ export default PlatformizedImport;
 
 ---
 
+### 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`.
+
+```tsx
+import React from 'react';
+import { CollectionPage } from '@wix/patterns/page';
+import { CustomColumns, ImportButton, Table } from '@wix/patterns';
+import {
+  usePlatformizedSource,
+  useTableCollection,
+} from '@wix/patterns/schema';
+
+type Product = {
+  id: string;
+  name: string;
+  sku: string;
+};
+
+// A platformized entity driven by a source (`usePlatformizedSource`). Like the
+// CMS case, the source supplies the columns and the fields to map onto — you
+// don't hand-list `fields`. Unlike CMS you still name the `destination`: a
+// platformized target has no Wix Data collection to derive it from.
+// (In these docs `usePlatformizedSource` is backed by in-memory data so it runs
+// with no backend.)
+function PlatformizedSourceImport() {
+  const source = usePlatformizedSource<Product>({
+    fqdn: 'stores.catalog.product',
+    backend: { find: async () => ({ items: [], total: 0 }) },
+    itemKey: (product) => product.id,
+    itemName: (product) => product.name,
+  });
+  const state = useTableCollection<Product>(source);
+
+  return (
+    <CollectionPage>
+      <CollectionPage.Header title={{ text: 'Products' }} />
+      <CollectionPage.Content>
+        <Table
+          state={state}
+          horizontalScroll
+          customColumns={<CustomColumns />}
+          columns={[]}
+          importButton={
+            <ImportButton
+              config={{ destination: { storesCatalogProducts: {} } }}
+            />
+          }
+        />
+      </CollectionPage.Content>
+    </CollectionPage>
+  );
+}
+
+export default PlatformizedSourceImport;
+```
+
+---
+
 ### Required fields
 
-Mark fields with `required: true`. The import is blocked while any required field is still unmapped, with a footnote listing the missing ones. (Shown with `usePlatformizedImport`.)
+Mark fields with `required: true`. The import is blocked while any required field is still unmapped, with a footnote listing the missing ones. (Shown with a platformized `config`.)
 
 ```tsx
 import { Page } from '@wix/design-system';
@@ -230,8 +264,8 @@ import {
   PageWrapper,
   Table,
   ToolbarTitle,
-  usePlatformizedImport,
   useTableCollection,
+  type ImportConfig,
 } from '@wix/patterns';
 import { queryStoreVariants } from '@wix/ambassador-stores-catalog-v1-product/http';
 import { StoreVariant } from '@wix/ambassador-stores-catalog-v1-product/types';
@@ -258,15 +292,14 @@ function RequiredFields() {
 
   // Mark fields `required: true`. The import is blocked while any required field
   // is still unmapped, with a footnote listing the missing ones.
-  const importProps = usePlatformizedImport({
-    state,
+  const importConfig: ImportConfig = {
     destination: { storesCatalogProducts: {} },
     fields: [
       { id: 'name', header: 'Name', required: true },
       { id: 'price', header: 'Price', required: true },
       { id: 'sku', header: 'SKU' },
     ],
-  });
+  };
 
   return (
     <PageWrapper>
@@ -280,7 +313,7 @@ function RequiredFields() {
             columns={[
               { title: 'Name', render: (variant) => variant.productName },
             ]}
-            importButton={<ImportButton {...importProps} />}
+            importButton={<ImportButton config={importConfig} />}
           />
         </Page.Content>
       </Page>
@@ -295,49 +328,31 @@ export default RequiredFields;
 
 ### Create new field
 
-A CMS capability: when the collection’s schema permits adding fields, unmapped CSV columns default to creating a new field (with an "Edit field" affordance) instead of being skipped. `useSchemaImport` wires it from the schema automatically.
+A CMS capability: when the collection’s schema permits adding fields, unmapped CSV columns default to creating a new field (with an "Edit field" affordance) instead of being skipped. `` wires it from the schema automatically.
 
 ```tsx
 import React from 'react';
 import { CollectionPage } from '@wix/patterns/page';
-import {
-  CustomColumns,
-  ImportButton,
-  Table,
-  tableSchemaSource,
-  useSchemaImport,
-  useTableCollection,
-} from '@wix/patterns';
-import { createInMemorySchemaSource } from '@wix/patterns/testkit';
+import { CustomColumns, ImportButton, Table } from '@wix/patterns';
+import { useTableCollection } from '@wix/patterns/schema';
+import { useCmsSchemaSource } from '@wix/patterns-cms';
 
 type CmsItem = {
   _id: string;
   name: string;
+  price: string;
 };
 
-// "Create new field" is a CMS (Wix Data) capability. `useSchemaImport` wires it
-// automatically: when the collection's schema permits adding fields
-// (`schemaPermissions.createField`), CSV columns that don't match an existing
-// field default to creating a new field (with an "Edit field" affordance)
-// instead of being skipped. Here only `name` exists, so other CSV columns become
-// new fields. (In a real app the source is `createCmsSchemaSource`.)
+// "Create new field" is a CMS (Wix Data) capability, wired automatically: when
+// the collection's schema permits adding fields (`schemaPermissions.createField`),
+// CSV columns that don't match an existing field default to creating a new field
+// (with an "Edit field" affordance) instead of being skipped. It's read off the
+// table's schema source, so `<ImportButton />` takes no config.
 function CreateNewField() {
-  const [schemaSource] = React.useState(() => {
-    const { source } = createInMemorySchemaSource<CmsItem>({
-      collectionId: 'Products',
-      fields: [{ id: 'name', displayName: 'Name', type: 'SHORT_TEXT' }],
-      items: [{ _id: '1', name: 'Coffee Mug' }],
-      schemaPermissions: {
-        createField: true,
-        updateField: true,
-        deleteField: true,
-      },
-    });
-    return tableSchemaSource(source);
-  });
-
-  const state = useTableCollection<CmsItem>(schemaSource.collectionConfig);
-  const importProps = useSchemaImport(schemaSource);
+  // (In these docs `useCmsSchemaSource` is backed by in-memory data — with
+  // add-field allowed — so it runs with no backend.)
+  const source = useCmsSchemaSource<CmsItem>({ collectionId: 'Products' });
+  const state = useTableCollection<CmsItem>(source);
 
   return (
     <CollectionPage>
@@ -346,10 +361,9 @@ function CreateNewField() {
         <Table
           state={state}
           horizontalScroll
-          fieldsSource={schemaSource}
           customColumns={<CustomColumns />}
           columns={[]}
-          importButton={<ImportButton {...importProps} />}
+          importButton={<ImportButton />}
         />
       </CollectionPage.Content>
     </CollectionPage>
@@ -368,42 +382,26 @@ A CMS behavior: when a CSV column maps to the collection’s id field (`_id`), t
 ```tsx
 import React from 'react';
 import { CollectionPage } from '@wix/patterns/page';
-import {
-  CustomColumns,
-  ImportButton,
-  Table,
-  tableSchemaSource,
-  useSchemaImport,
-  useTableCollection,
-} from '@wix/patterns';
-import { createInMemorySchemaSource } from '@wix/patterns/testkit';
+import { CustomColumns, ImportButton, Table } from '@wix/patterns';
+import { useTableCollection } from '@wix/patterns/schema';
+import { useCmsSchemaSource } from '@wix/patterns-cms';
 
 type CmsItem = {
   _id: string;
   name: string;
+  price: string;
 };
 
 // Update-or-skip-by-ID is a CMS (Wix Data) behavior. When a CSV column maps to
 // the collection's id field (`_id`), that row floats to the top and the modal
-// offers an "update or skip" write policy for rows that collide on ID. Include
-// the id field in the schema so it's mappable; `useSchemaImport` derives the id
-// field from the schema. (In a real app the source is `createCmsSchemaSource`.)
+// offers an "update or skip" write policy for rows that collide on ID. The id
+// field comes from the schema source, so it's mappable and the import derives it
+// — `<ImportButton />` takes no config.
 function IdCollisionWritePolicy() {
-  const [schemaSource] = React.useState(() => {
-    const { source } = createInMemorySchemaSource<CmsItem>({
-      collectionId: 'Products',
-      idField: '_id',
-      fields: [
-        { id: '_id', displayName: 'ID', type: 'SHORT_TEXT' },
-        { id: 'name', displayName: 'Name', type: 'SHORT_TEXT' },
-      ],
-      items: [{ _id: '1', name: 'Coffee Mug' }],
-    });
-    return tableSchemaSource(source);
-  });
-
-  const state = useTableCollection<CmsItem>(schemaSource.collectionConfig);
-  const importProps = useSchemaImport(schemaSource);
+  // (In these docs `useCmsSchemaSource` is backed by in-memory data — including
+  // the `_id` field — so it runs with no backend.)
+  const source = useCmsSchemaSource<CmsItem>({ collectionId: 'Products' });
+  const state = useTableCollection<CmsItem>(source);
 
   return (
     <CollectionPage>
@@ -412,10 +410,9 @@ function IdCollisionWritePolicy() {
         <Table
           state={state}
           horizontalScroll
-          fieldsSource={schemaSource}
           customColumns={<CustomColumns />}
           columns={[]}
-          importButton={<ImportButton {...importProps} />}
+          importButton={<ImportButton />}
         />
       </CollectionPage.Content>
     </CollectionPage>
@@ -429,7 +426,7 @@ export default IdCollisionWritePolicy;
 
 ### Backup & error handling
 
-Pass a `backup` to snapshot the collection before importing (undone on cancel) and a `jobApplicationErrorMap` to map a failed job’s application-error codes to messages. (Shown with `usePlatformizedImport`.)
+Pass a `backup` to snapshot the collection before importing (undone on cancel) and a `jobApplicationErrorMap` to map a failed job’s application-error codes to messages. (Shown with a platformized `config`.)
 
 ```tsx
 import { Page } from '@wix/design-system';
@@ -439,8 +436,8 @@ import {
   PageWrapper,
   Table,
   ToolbarTitle,
-  usePlatformizedImport,
   useTableCollection,
+  type ImportConfig,
 } from '@wix/patterns';
 import { queryStoreVariants } from '@wix/ambassador-stores-catalog-v1-product/http';
 import { StoreVariant } from '@wix/ambassador-stores-catalog-v1-product/types';
@@ -465,8 +462,7 @@ function BackupAndErrorHandling() {
     fetchErrorMessage: () => 'Error fetching products',
   });
 
-  const importProps = usePlatformizedImport({
-    state,
+  const importConfig: ImportConfig = {
     destination: { storesCatalogProducts: {} },
     fields: [{ id: 'name', header: 'Name', required: true }],
 
@@ -490,7 +486,7 @@ function BackupAndErrorHandling() {
         message: `Missing required fields: ${data?.missingFields?.join(', ')}`,
       }),
     },
-  });
+  };
 
   return (
     <PageWrapper>
@@ -504,7 +500,7 @@ function BackupAndErrorHandling() {
             columns={[
               { title: 'Name', render: (variant) => variant.productName },
             ]}
-            importButton={<ImportButton {...importProps} />}
+            importButton={<ImportButton config={importConfig} />}
           />
         </Page.Content>
       </Page>
@@ -521,7 +517,7 @@ export default BackupAndErrorHandling;
 
 | Prop | Type | Required | Default | Description |
 |------|------|----------|---------|-------------|
-| `config` | `ImportButtonConfig` | Yes | - | The import inputs. Build it with a source hook — `useSchemaImport` for a CMS (Wix Data) collection, or `usePlatformizedImport` for a platformized destination — and pass the returned `config`. |
-| `renderFieldEditor` | `RenderImportFieldEditor` | No | - | Renders the source's create/edit-field modal (see {@link RenderImportFieldEditor}). Supplied by consumer-driven sources (e.g. `useSchemaImport` for CMS). A DataExtension destination provides its own internally, so it need not be passed for that case. |
+| `config` | `ImportConfig` | No | - | The import inputs, as a plain object. Omit it entirely to import into the table's own collection (Wix Data) — the collection, its fields, and create-new-field are read from the table's source. Set `destination` (and any `fields`) to write to a platformized target instead. |
+| `renderFieldEditor` | `RenderImportFieldEditor` | No | - | Overrides the create/edit-field modal (see {@link RenderImportFieldEditor}). By default the editor is chosen from the destination (CMS vs DataExtension) and loaded on demand, so this need not be passed. |
 | `toolbarType` | `"bulkActionToolbar" \| "default"` | No | - | Which button variant to render. `'default'` (the default) shows a `ResponsiveButton`; `'bulkActionToolbar'` shows a compact secondary `Button`. |
 

package/dist/docs/MultiBulkActionToolbar.md

@@ -541,7 +541,7 @@ import {
   ChangeOrder,
   Block,
   UploadExport,
-} from '@wix/wix-ui-icons-common';
+} from '@wix/wix-ui-icons-common/lazy';
 import { contacts } from '@wix/crm';
 
 type ContactsFilters = {
@@ -549,7 +549,6 @@ type ContactsFilters = {
 };
 
 function BulkActionsWithDividers() {
-
   const state = useTableCollection<contacts.Contact, ContactsFilters>({
     queryName: 'MultiBulkActionToolbar-BulkActions',
     fetchData: (query: OffsetQuery<ContactsFilters>) => {

package/dist/docs/PickerContent.md

@@ -112,7 +112,8 @@ export function PickerModalExample() {
 | `showSelectedCount` | `boolean` | No | - | Displays count of selected items in <CustomModalLayout /> `sideActions` |
 | `title` | `ReactNode` | No | - | Sets text title for the modal; can be used in conjunction with other components |
 | `subtitle` | `ReactNode` | No | - | Sets text subtitle for the modal; can be used in conjunction with other components |
-| `content` | `ReactNode` | No | - | Contains all modal's content in its middle area. `<CustomModalLayout/>` children are passed as `content`, too. |
+| `content` | `ReactNode` | No | - | Sets the modal's main content, rendered in the middle scrollable area. When omitted, `children` are rendered in this area instead. |
+| `children` | `ReactNode` | No | - | Sets the modal's content. Rendered in the middle scrollable area when `content` is omitted; when `content` is provided, rendered directly inside the modal root after the layout blocks, so fully custom nodes can be mounted and animated. |
 | `primaryButtonText` | `ReactNode` | No | - | Sets text label or other content (e.g., <Loader/>) for the primary button |
 | `primaryButtonProps` | `Omit<ButtonProps, "internalDataHook">` | No | - | Passes on any `<Button/>` properties on the primary button |
 | `primaryButtonOnClick` | `(() => void)` | No | - | Defines a call-back function after user clicks on the primary button |
@@ -140,7 +141,7 @@ export function PickerModalExample() {
 | `helpButtonProps` | `ModalControlButtonProps` | No | - | Help button props. |
 | `onCloseButtonClick` | `MouseEventHandler<HTMLButtonElement>` | No | - | @deprecated use `closeButtonProps` instead. |
 | `onHelpButtonClick` | `MouseEventHandler<HTMLButtonElement>` | No | - | @deprecated use `helpButtonProps` instead. |
-| `skin` | `"standard" \| "premium" \| "destructive"` | No | - | a global skin for the modal, will be applied as stylable state and will affect footer buttons skin. |
+| `skin` | `"standard" \| "premium" \| "destructive"` | No | - | a global skin for the modal, will affect footer buttons skin. |
 | `autoAdditionalStepOnInitialSelect` | `boolean` | No | - | When true, the picker will start directly on the additional step, skipping the first selection step. The back button will also be hidden. |
 | `additionalStepTitle` | `string` | No | - | The additional step title |
 | `additionalStepSubtitle` | `string` | No | - | The additional step subtitle |

package/dist/docs/PickerModal.md

@@ -646,7 +646,8 @@ Integrating with `PickerModal` is usually done by the following steps
 | `multiple` | `MultipleSelection` | No | - | Limits the number of items that can be selected.<br> Either a boolean or a number. A number indicates the maximum number of selections, `true` indicates no limit, `false` indicates only 1 item (radio button will be shown instead of checkboxes) |
 | `title` | `ReactNode` | No | - | Sets text title for the modal; can be used in conjunction with other components |
 | `subtitle` | `ReactNode` | No | - | Sets text subtitle for the modal; can be used in conjunction with other components |
-| `content` | `ReactNode` | No | - | Contains all modal's content in its middle area. `<CustomModalLayout/>` children are passed as `content`, too. |
+| `content` | `ReactNode` | No | - | Sets the modal's main content, rendered in the middle scrollable area. When omitted, `children` are rendered in this area instead. |
+| `children` | `ReactNode` | No | - | Sets the modal's content. Rendered in the middle scrollable area when `content` is omitted; when `content` is provided, rendered directly inside the modal root after the layout blocks, so fully custom nodes can be mounted and animated. |
 | `primaryButtonText` | `ReactNode` | No | - | Sets text label or other content (e.g., <Loader/>) for the primary button |
 | `primaryButtonProps` | `Omit<ButtonProps, "internalDataHook">` | No | - | Passes on any `<Button/>` properties on the primary button |
 | `primaryButtonOnClick` | `(() => void)` | No | - | Defines a call-back function after user clicks on the primary button |
@@ -674,7 +675,7 @@ Integrating with `PickerModal` is usually done by the following steps
 | `helpButtonProps` | `ModalControlButtonProps` | No | - | Help button props. |
 | `onCloseButtonClick` | `MouseEventHandler<HTMLButtonElement>` | No | - | @deprecated use `closeButtonProps` instead. |
 | `onHelpButtonClick` | `MouseEventHandler<HTMLButtonElement>` | No | - | @deprecated use `helpButtonProps` instead. |
-| `skin` | `"standard" \| "premium" \| "destructive"` | No | - | a global skin for the modal, will be applied as stylable state and will affect footer buttons skin. |
+| `skin` | `"standard" \| "premium" \| "destructive"` | No | - | a global skin for the modal, will affect footer buttons skin. |
 
 ## BI
 

package/dist/docs/PrimaryActionButton.md

@@ -293,7 +293,7 @@ function OverrideButtonDefaults() {
 | `onKeyPressCapture` | `any` | No | - | @deprecated |
 | `onPointerEnterCapture` | `any` | No | - | @deprecated This event handler was always ignored by React. It was added by mistake to the types. |
 | `onPointerLeaveCapture` | `any` | No | - | @deprecated This event handler was always ignored by React. It was added by mistake to the types. |
-| `priority` | `"primary" \| "secondary"` | No | - | Specifies the priority of a button. |
+| `priority` | `"primary" \| "secondary" \| "tertiary"` | No | - | Specifies the priority of a button. |
 | `showTooltip` | `boolean` | No | - | Specifies whether the full button label is displayed in a tooltip when label overflows available space. Behaviour is enabled by default. Set property value to false to show ellipsis without a tooltip. |
 | `tooltipProps` | `TooltipCommonProps` | No | - | Allows to pass all common tooltip props. Use it to customize a tooltip created from text ellipsis. @linkTypeTo components-overlays--tooltip |
 

package/dist/docs/PrimaryPageButton.md

@@ -133,7 +133,7 @@ function Overriding() {
 | `onKeyPressCapture` | `any` | No | - | @deprecated |
 | `onPointerEnterCapture` | `any` | No | - | @deprecated This event handler was always ignored by React. It was added by mistake to the types. |
 | `onPointerLeaveCapture` | `any` | No | - | @deprecated This event handler was always ignored by React. It was added by mistake to the types. |
-| `priority` | `"primary" \| "secondary"` | No | - | Specifies the priority of a button. |
+| `priority` | `"primary" \| "secondary" \| "tertiary"` | No | - | Specifies the priority of a button. |
 | `fullWidth` | `boolean` | No | - | Sets button width to fill a 100% of a parent container width. |
 | `showTooltip` | `boolean` | No | - | Specifies whether the full button label is displayed in a tooltip when label overflows available space. Behaviour is enabled by default. Set property value to false to show ellipsis without a tooltip. |
 | `tooltipProps` | `TooltipCommonProps` | No | - | Allows to pass all common tooltip props. Use it to customize a tooltip created from text ellipsis. @linkTypeTo components-overlays--tooltip |