@wix/auto-patterns 1.22.0 → 1.24.0

package/dist/docs/bulk_actions.md

@@ -106,11 +106,15 @@ Custom bulk actions execute JavaScript code that you define for bulk operations.
              a.click();
 
              // Update server with export timestamp
-             return await schema.actions.update(items);
+             // Handle potential undefined schema
+             if (schema) {
+               return await schema.actions.update(items);
+             }
+             return items; // fallback when schema is unavailable
            },
            successToast: `${selectedValues.length} pets exported`,
            errorToast: (err, {retry}) => ({
-             text: 'Export failed',
+             message: 'Export failed',
              action: { text: 'Retry', onClick: retry }
            })
          });
@@ -194,10 +198,7 @@ The bulk action toolbar uses a specific structure for organizing actions:
         "item": {
           "id": "bulkCustom",
           "type": "custom",
-          "label": "Custom Bulk",
-          "custom": {
-            "id": "MyCustomBulk"
-          }
+          "label": "Custom Bulk"
         }
       }
     },

package/dist/docs/collection_page_actions.md

@@ -87,11 +87,15 @@ Custom collection page actions execute JavaScript code that you define for colle
                // Your collection export logic here
                console.log(`Exporting collection: ${collectionId}`);
                // Export and update all items on server
-               return await schema.actions.bulkUpdate({ lastExported: new Date() });
+               // Handle potential undefined schema
+               if (schema) {
+                 return await schema.actions.bulkUpdate({ lastExported: new Date() });
+               }
+               return Promise.resolve(); // fallback when schema is unavailable
              },
              successToast: 'Collection exported successfully',
              errorToast: (err, {retry}) => ({
-               text: 'Export failed',
+               message: 'Export failed',
                action: { text: 'Retry', onClick: retry }
              })
            }
@@ -314,10 +318,16 @@ export const quickToggle: CustomActionCollectionPageActionOnRowClickResolver = (
       const updatedItem = { ...item, isActive: !item.isActive };
 
       optimisticActions.updateOne(updatedItem, {
-        submit: async (items) => schema.actions.update(items[0]),
+        submit: async (items) => {
+          // Handle potential undefined schema
+          if (schema) {
+            return await schema.actions.update(items[0]);
+          }
+          return items[0]; // fallback when schema is unavailable
+        },
         successToast: `${item.name} toggled successfully`,
         errorToast: (err, {retry}) => ({
-          text: 'Toggle failed',
+          message: 'Toggle failed',
           action: { text: 'Retry', onClick: retry }
         })
       });

package/dist/docs/custom_overrides.md

@@ -108,14 +108,73 @@ Each column in the table has a default rendering based on its field type. You ca
 
 ### Function Signature
 
+For proper TypeScript support, use the `IColumnValue<T>` interface:
+
 ```typescript
-function columnOverride({ value, row }) {
-  // value: The individual column value
-  // row: The entire row object containing all field values
+import { IColumnValue } from '@wix/auto-patterns/types';
+
+function columnOverride(props: IColumnValue<string>) {
+  // props.value: The individual column value (typed)
+  // props.row: The entire row object containing all field values
   return <YourCustomRendering />;
 }
 ```
 
+### Type-Specific Examples
+
+The generic type `T` in `IColumnValue<T>` should match your field's data type:
+
+```tsx
+import React from 'react';
+import { IColumnValue } from '@wix/auto-patterns/types';
+import { Badge } from '@wix/design-system';
+
+/* The `IColumnValue<T>` interface provides type safety for column override functions: */
+interface IColumnValue<T> {
+  value: T;                    // The individual column value (strongly typed)
+  row: Record<string, any>;    // The entire row object with all field values
+}
+
+// For TEXT fields
+export function petName({ value, row }: IColumnValue<string>) {
+  return <span>{value?.toUpperCase()}</span>;
+}
+
+// For NUMBER fields
+export function age({ value, row }: IColumnValue<number>) {
+  return (
+    <Badge skin={value > 5 ? 'warning' : 'success'}>
+      {value} years old
+    </Badge>
+  );
+}
+
+// For BOOLEAN fields
+export function isVaccinated({ value, row }: IColumnValue<boolean>) {
+  return (
+    <Badge skin={value ? 'success' : 'danger'}>
+      {value ? '✓ Vaccinated' : '✗ Not Vaccinated'}
+    </Badge>
+  );
+}
+
+// For DATE/DATETIME fields
+export function birthDate({ value, row }: IColumnValue<string | Date>) {
+  const date = value instanceof Date ? value : new Date(value);
+  return <span>{date.toLocaleDateString()}</span>;
+}
+
+// For IMAGE fields
+export function profilePicture({ value, row }: IColumnValue<string>) {
+  return <img src={value} alt={row.name} width="48" height="48" />;
+}
+
+// For ARRAY fields
+export function hobbies({ value, row }: IColumnValue<string[]>) {
+  return <span>{value?.join(', ') || 'No hobbies'}</span>;
+}
+```
+
 ### Understanding Row Data
 
 **Important**: The `row` object contains all field values from the entity, where each property corresponds to a **field ID** from the collection schema. To access specific field values, use the exact field ID as defined in your collection schema.
@@ -156,22 +215,29 @@ export function myColumn({ value, row }) {
 
 In `components/columns/name.tsx`:
 
-```ts
+```tsx
 import React from 'react';
+import { IColumnValue } from '@wix/auto-patterns/types';
 
-export function name({ value, row }) {
-  // Simple value formatting
+export function name(props: IColumnValue<string>) {
+  // Simple value formatting with TypeScript typing
+  return <strong>{props.value}</strong>;
+}
+
+// Alternative: Destructured parameters with typing
+export function nameAlt({ value, row }: IColumnValue<string>) {
   return <strong>{value}</strong>;
 }
 ```
 
 In `components/columns/petInfo.tsx`:
 
-```ts
+```tsx
 import React from 'react';
 import { Box, Text } from '@wix/design-system';
+import { IColumnValue } from '@wix/auto-patterns/types';
 
-export function petInfo({ value, row }) {
+export function petInfo({ value, row }: IColumnValue<string>) {
   // Complex column combining multiple row values
   return (
     <Box direction="vertical" gap={1}>
@@ -189,11 +255,12 @@ export function petInfo({ value, row }) {
 
 In `components/columns/status.tsx`:
 
-```ts
+```tsx
 import React from 'react';
 import { Badge } from '@wix/design-system';
+import { IColumnValue } from '@wix/auto-patterns/types';
 
-export function status({ value, row }) {
+export function status({ value, row }: IColumnValue<string>) {
   // Conditional rendering based on multiple row fields
   if (row.isVaccinated && row.age > 1) {
     return <Badge skin="success">Ready for Adoption</Badge>;
@@ -207,10 +274,11 @@ export function status({ value, row }) {
 
 In `components/columns/fullName.tsx`:
 
-```ts
+```tsx
 import React from 'react';
+import { IColumnValue } from '@wix/auto-patterns/types';
 
-export function fullName({ value, row }) {
+export function fullName({ value, row }: IColumnValue<string>) {
   // Calculated column using multiple fields
   return `${row.name} (owned by ${row.owner})`;
 }
@@ -218,10 +286,11 @@ export function fullName({ value, row }) {
 
 In `components/columns/date.tsx`:
 
-```ts
+```tsx
 import React from 'react';
+import { IColumnValue } from '@wix/auto-patterns/types';
 
-export function date({ value, row }) {
+export function date({ value, row }: IColumnValue<string>) {
   // Access to other row data for enhanced date formatting
   const isRecent = row.lastActivity && new Date(row.lastActivity) > new Date(Date.now() - 7 * 24 * 60 * 60 * 1000);
 
@@ -304,6 +373,8 @@ PatternsWizardOverridesProvider
 
 ### Important Guidelines
 
+- **TypeScript Usage**: Always use `IColumnValue<T>` and import it from `@wix/auto-patterns/types`
+- **Type Matching**: Ensure the generic type `T` matches your field's actual data type (string, number, boolean, etc.)
 - **Performance**: Remember that column functions are called for every row, so keep calculations lightweight
 - **Consistency**: When using row data, ensure the column header accurately represents what's displayed
 - **Accessibility**: Maintain proper semantic structure when combining multiple values
@@ -922,7 +993,7 @@ import * as columns from './components/columns';
 import * as actions from './components/actions';
 
 <PatternsWizardOverridesProvider value={{ sections, columns, actions }}>
-  <AutoPatternsApp configuration={config as AppConfig} />
+  <AutoPatternsApp configuration={config} />
 </PatternsWizardOverridesProvider>
 ```
 

package/dist/docs/entity_page.md

@@ -11,8 +11,72 @@ All entity pages must have:
 
 * Displays details for a **single entity**.
 * Always tied to a single Wix collection.
+* Supports **two distinct modes**: **view mode** and **edit mode** with separate page configurations.
 
-> The custom actions must be defined inside the `moreActions` array.
+## Entity Page Modes
+
+AutoPatterns supports two entity page modes that can be configured as separate pages:
+
+### Edit Mode (Default)
+- **Purpose**: Allows users to modify entity data
+- **UI**: Uses `@wix/patterns` `EntityPage` component with built-in Save/Cancel actions
+- **Actions**: Only supports `moreActions` (custom actions in the "more" menu)
+- **Default Mode**: When `mode` is not specified, defaults to edit mode
+
+### View Mode
+- **Purpose**: Displays entity data in read-only format with rich action capabilities
+- **Actions**: Supports `primaryActions`, `secondaryActions`, and `moreActions` (collection-style actions)
+- **Mode**: Must be explicitly set with `mode: 'view'`
+
+
+## Routing Patterns
+
+When implementing both view and edit modes for the same entity, use these routing patterns:
+
+- **View Mode**: `/entity/:entityId` (e.g., `/product/:productId`)
+- **Edit Mode**: `/entity/edit/:entityId` (e.g., `/product/edit/:productId`)
+
+This pattern allows:
+- Clear distinction between view and edit URLs
+- Natural navigation flow between modes
+
+## View Mode: Purpose and API
+
+### Purpose of View Mode
+View mode is primarily intended for **read-only entity presentation** with rich action capabilities by default; however, it also supports interactive or editable custom components if needed:
+
+- **Data Display**: Present entity information in a clean, read-only format
+- **Action Hub**: Provide primary, secondary, and more actions for entity operations
+- **Navigation Center**: Enable seamless transitions to edit mode and other workflows
+- **Rich Content**: Display images, rich text, and complex data types optimally
+
+
+See [Entity Page View Actions](./entity_page_view_actions.md) for detailed action configuration.
+
+#### Out-of-the-Box Features
+
+**Automatic Edit Navigation**: When a corresponding edit mode page exists, view mode automatically adds an "Edit [EntityName]" action to the more actions menu.
+
+**Back Navigation**: Automatic "Back" button that navigates to the parent collection page.
+
+## Action Configuration
+
+Entity page action configuration depends on the mode:
+
+- **Edit Mode**: Supports only `moreActions`. See [Entity Page Actions](./entity_page_actions.md)
+- **View Mode**: Supports full action API (`primaryActions`, `secondaryActions`, `moreActions`). See [Entity Page View Actions](./entity_page_view_actions.md)
+
+### Edit Mode Actions
+- **Supported**: `moreActions` only
+- **Built-in**: Save and Cancel actions are automatically provided
+- **Custom Actions**: Must be defined in the `moreActions` array
+
+### View Mode Actions
+- **Supported**: `primaryActions`, `secondaryActions`, and `moreActions`
+- **Pattern**: Follows collection page action patterns
+- **Flexibility**: Full control over all action areas
+
+> The custom actions must be defined inside the `moreActions` array for edit mode, but view mode supports actions in all areas.
 
 > Note: You do not need to define a custom action to navigate to the entity page. This behavior is built-in — clicking on a row in the collection table automatically navigates to the corresponding entity page.
 

package/dist/docs/entity_page_actions.md

@@ -1,8 +1,10 @@
-## Entity Page Actions: `moreActions` Support
+## Entity Page Edit Mode Actions: `moreActions` Support
 
-Entity pages in AutoPatternsApp support not only a primary action (such as "Save" or "Delete") but also a flexible set of **more actions** (sometimes called "secondary actions" or `moreActions`). These allow you to provide additional contextual actions for the entity, such as custom logic, or grouped actions.
+Entity pages in **edit mode** support not only built-in actions (such as "Save" and "Cancel") but also a flexible set of **more actions** (sometimes called "secondary actions" or `moreActions`). These allow you to provide additional contextual actions for the entity, such as custom logic, or grouped actions.
 
-> **Note:** All custom actions for entity pages must be placed in the `moreActions` array. Do not place custom actions as primary actions on entity pages. The `moreActions` array is the only supported location for custom actions on entity pages.
+> **Note:** This documentation covers **edit mode** entity pages only. Edit mode supports only `moreActions`. For **view mode** entity pages that support `primaryActions`, `secondaryActions`, and `moreActions`, see [Entity Page View Actions](./entity_page_view_actions.md).
+
+> **Edit Mode Limitation:** All custom actions for edit mode entity pages must be placed in the `moreActions` array. Do not place custom actions as primary actions on edit mode entity pages. The `moreActions` array is the only supported location for custom actions on edit mode entity pages.
 
 ### Configuration Structure
 
@@ -39,16 +41,16 @@ Entity pages in AutoPatternsApp support not only a primary action (such as "Save
 
 ---
 
-### CustomEntityPageMoreActionsActionResolver
+### CustomEntityPageActionResolver
 
-The `CustomEntityPageMoreActionsActionResolver` type is used to implement custom actions for the `moreActions` menu on entity pages in AutoPatternsApp. Each action in the `moreActions` array must have a corresponding resolver function registered in your overrides.
+The `CustomEntityPageActionResolver` type is used to implement custom actions for the `moreActions` menu on entity pages in AutoPatternsApp. Each action in the `moreActions` array must have a corresponding resolver function registered in your overrides.
 
 #### Function Signature
 
 ```typescript
-import { CustomEntityPageMoreActionsActionResolver } from '@wix/auto-patterns/types';
+import { CustomEntityPageActionResolver } from '@wix/auto-patterns/types';
 
-export const myMoreAction: CustomEntityPageMoreActionsActionResolver = (params) => {
+export const myMoreAction: CustomEntityPageActionResolver = (params) => {
   const { actionParams: { entity, form } , sdk } = params;
 
   return {
@@ -67,10 +69,10 @@ export const myMoreAction: CustomEntityPageMoreActionsActionResolver = (params)
 
 ---
 
-#### Key Points for CustomEntityPageMoreActionsActionResolver
+#### Key Points for CustomEntityPageActionResolver
 
 - The action `id` in the configuration MUST exactly match the function name exported from your actions folder.
-- The implementation must use the `CustomEntityPageMoreActionsActionResolver` type.
+- The implementation must use the `CustomEntityPageActionResolver` type.
 - The implementation must be exported as a named export (not default export).
 - The function receives `{ actionParams, sdk }` as parameters.
 - The returned object must include at least a `label` and an `onClick` handler (optionally an `icon`).
@@ -83,10 +85,10 @@ export const myMoreAction: CustomEntityPageMoreActionsActionResolver = (params)
 ✓ Each action type only includes its required field(s)
 ✓ Custom actions match implementations in overrides
 ✓ The resolver is exported and registered in the `actions` property of your `PatternsWizardOverridesProvider`
-✓ The function signature matches `CustomEntityPageMoreActionsActionResolver`
+✓ The function signature matches `CustomEntityPageActionResolver`
 ✓ The returned object includes `label`, `onClick`, and optionally `icon`
 
 ---
 
 **Summary:**
-The `CustomEntityPageMoreActionsActionResolver` enables you to add custom, contextual actions to the "More Actions" menu on your entity pages. Implement the resolver, export it, and reference it by `id` in your config for seamless integration.
+The `CustomEntityPageActionResolver` enables you to add custom, contextual actions to the "More Actions" menu on your entity pages. Implement the resolver, export it, and reference it by `id` in your config for seamless integration.

package/dist/docs/entity_page_view_actions.md

@@ -0,0 +1,137 @@
+# Entity Page View Mode Actions
+
+View mode supports the complete collection-style actions API, providing maximum flexibility for entity operations.
+
+## Supported Action Types
+
+### Primary Actions
+The main call-to-action, typically for the most common operation:
+
+```typescript
+primaryActions: {
+  type: 'action',
+  action: {
+    item: {
+      id: 'createEntity',
+      label: 'Create New',
+      type: 'create',
+      create: {
+        mode: 'page',
+        page: { id: 'EntityEditPageId' }
+      }
+    }
+  }
+}
+```
+
+### Secondary Actions
+Supporting actions displayed alongside primary actions:
+
+```typescript
+secondaryActions: {
+  type: 'action',
+  action: {
+    item: {
+      id: 'duplicateEntity',
+      label: 'Duplicate',
+      type: 'custom',
+    }
+  }
+}
+```
+
+### More Actions
+Additional contextual actions in dropdown menu:
+
+```typescript
+moreActions: [
+  {
+    id: 'shareEntity',
+    type: 'custom',
+    label: 'Share',
+  }
+]
+```
+
+## Action Menu Support
+
+View mode also supports menu-style actions for grouping related operations:
+
+```typescript
+primaryActions: {
+  type: 'menu',
+  menu: {
+    label: 'Actions',
+    items: [
+      {
+        id: 'duplicateProduct',
+        label: 'Duplicate',
+        type: 'custom',
+      },
+      { type: 'divider' },
+      {
+        id: 'shareProduct',
+        type: 'custom',
+        label: 'Share'
+      }
+    ]
+  }
+}
+```
+
+## Automatic Edit Action
+
+View mode automatically provides an "Edit [EntityName]" action in the more actions menu when:
+- An edit mode page exists for the same collection
+- The edit page has no explicit mode or `mode: 'edit'`
+- The view page has `mode: 'view'`
+
+This action is automatically added and doesn't need to be configured manually.
+
+## Action Resolvers
+
+View mode actions follow the same resolver patterns as collection page actions:
+
+### For Standard Actions (create)
+These actions are handled automatically by the AutoPatterns framework using the configuration provided.
+
+### For Custom Actions
+Custom actions require resolver implementations:
+
+```typescript
+import { CustomEntityPageActionResolver } from '@wix/auto-patterns/types';
+
+export const duplicateProduct: CustomEntityPageActionResolver = (params) => {
+  const { actionParams: { entity }, sdk } = params;
+
+  const schema = sdk.getSchema(sdk.collectionId);
+  return {
+    label: 'Duplicate Product',
+    icon: <DuplicateIcon />, // optional
+    onClick: async () => {
+      // Your custom duplication logic here
+      await schema.actions.create({
+        ...entity,
+        name: `${entity.name} (Copy)`
+      });
+    },
+  };
+};
+```
+
+## Best Practices
+
+### When to Use Each Action Type
+
+**Primary Actions**: Use for the most common user action (typically "Create" or main workflow action)
+
+**Secondary Actions**: Use for supporting workflows like "Duplicate"
+
+**More Actions**: Use for:
+- Less common operations
+- Administrative functions
+- Actions that need confirmation
+
+### Navigation Patterns
+
+1. **View → Create**: Use primary actions with `type: 'create'`

package/dist/docs/index.md

@@ -43,8 +43,12 @@ This index maps user requests to the appropriate section IDs for fetching releva
 **Keywords**: entity page layout, detail page configuration, field arrangement, layout structure, grid system, column spans, main/sidebar sections, field grouping, container usage, custom components, 12-column grid
 
 ### ID: `entity_page_actions`
-**Topics**: Entity page actions, moreActions, custom entity actions
-**Keywords**: entity page actions, detail page operations, moreActions, secondary actions, custom entity actions, entity-specific operations, action menus
+**Topics**: Entity page edit mode actions, moreActions, custom entity actions
+**Keywords**: entity page actions, edit mode actions, moreActions, custom entity actions, entity-specific operations, action menus
+
+### ID: `entity_page_view_actions`
+**Topics**: Entity page view mode actions, primaryActions, secondaryActions, collection-style actions
+**Keywords**: view mode actions, primaryActions, secondaryActions, read-only entity actions, entity page view operations, collection-style entity actions, navigation actions
 
 ### ID: `installation`
 **Topics**: Package installation, setup process, component integration, provider setup

package/dist/docs/pages_configuration.md

@@ -5,7 +5,6 @@
 - **Pages array must contain exactly two pages** - one collectionPage and one entityPage
 - **Exactly one page must have `appMainPage: true`** to designate it as the main page
 - **All page IDs referenced in relationships must exist in the configuration** - validate all `parentPageId` and `entityPageId` references
-- **Bind `type` strictly to matching fields** - if `type: 'collectionPage'`, only `collectionPage` field exists (no `entityPage` field), and vice versa
 
 ## Default Generation
 
@@ -18,12 +17,6 @@
     * The route path **must** include a descriptive segment (e.g., `/product/:entityId`, `/pet/:entityId`)
     * **Never use just `/:entityId`** - this conflicts with the collection page route and breaks routing
 
-## Type and Structure Binding
-
-* If `type: 'collectionPage'`, then **only** `collectionPage` field exists (no `entityPage` field).
-* If `type: 'entityPage'`, then **only** `entityPage` field exists (no `collectionPage` field).
-* **No cross-mixing** allowed.
-
 ## Page Connection Configuration
 
 ### Main Page Designation
@@ -88,11 +81,8 @@ A two-way connection must be established between collection pages and entity pag
 * **Route Structure**: Entity pages must use `/[segment]/:entityId` format (e.g., `/product/:entityId` or `/pets/:entityId`), never just `/:entityId`
 * **Route Parameters Configuration**: All entity pages must have both a dynamic parameter in `route.path` and a matching configuration in `route.params`
 
-## ⚠️ Common Type and Route Mistakes to Avoid
+## ⚠️ Common Route and Configuration Mistakes to Avoid
 
-- Using incorrect field types
-- Missing required fields
-- Including fields from wrong page type
 - Missing route.params for entity pages
 - Using `/:entityId` instead of `/segment/:entityId` for entity page routes (causes routing conflicts)
 

package/dist/docs/sdk_utilities.md

@@ -48,9 +48,15 @@ const optimisticActions = sdk.getOptimisticActions(sdk.collectionId);
 const schema = sdk.getSchema(sdk.collectionId);
 
 optimisticActions.operation(items, {
-  submit: async (items) => schema.actions.serverMethod(items),
+  submit: async (items) => {
+    // Handle potential undefined schema
+    if (schema) {
+      return await schema.actions.serverMethod(items);
+    }
+    return items; // fallback when schema is unavailable
+  },
   successToast: 'Success message',
-  errorToast: (err, {retry}) => ({ text: 'Error message', action: { text: 'Retry', onClick: retry }})
+  errorToast: (err, {retry}) => ({ message: 'Error message', action: { text: 'Retry', onClick: retry }})
 });
 ```
 
@@ -81,7 +87,7 @@ interface OptimisticParams<T> {
 }
 
 interface ToastConfig {
-  text: string;
+  message: string; // Note: Use 'message' property, not 'text'
   action?: { text: string; onClick: () => void };
 }
 ```
@@ -90,8 +96,9 @@ interface ToastConfig {
 
 **Before using optimistic actions:**
 - Verify `sdk.getOptimisticActions(collectionId)` returns valid instance
-- Verify `sdk.getSchema(collectionId)` returns valid schema
+- **Always check for undefined schema**: `sdk.getSchema(collectionId)` can return `undefined` - handle this case in your submit functions
 - For delete operations: `showUndoToast: true` is mandatory
 - All `submit` functions must return a Promise
+- **Toast property**: Use `message` property in ToastConfig, not `text`
 
 **SDK Parameter:** Available in custom actions and modals. See SDK Utilities section for complete interface.