@wix/patterns 1.468.0 → 1.470.0

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

@@ -0,0 +1,186 @@
+# Reading the Doc Indices
+
+**Category:** Guides
+
+Paths written as `dist/…` below are relative to the `@wix/patterns` package root — the directory holding its `package.json`.
+
+## Overview
+
+`@wix/patterns` ships two machine-readable indices under `dist/`, and they answer different
+questions. This is what their conventions mean, so a consumer reading them does not mistake
+a deliberate stub for a truncated file.
+
+| Index | Covers | Use it for |
+| --- | --- | --- |
+| `dist/docs/index.json` | every documented name — components, hooks, factories, state types, guides | finding a name's doc, its examples, and the guides |
+| `dist/dts-bundle/index.json` | a curated set of names | reading a real, fully-resolved declaration |
+
+The docs index is the larger of the two: everything documented has an entry, while the
+bundle index is deliberately curated. A name absent from the bundle index is not
+undocumented — look it up in the docs index.
+
+## What an entry can carry
+
+| Field | Meaning |
+| --- | --- |
+| `file` | the doc, relative to `dist/docs/` |
+| `category` | the Storybook path the doc was authored under |
+| `importPath` | the subpath to import this name from — take it from here rather than opening the page |
+| `bundle` | the declaration file that holds this name's props, relative to `dist/dts-bundle/` |
+| `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 |
+| `status`, `statusMessage` | see *Lifecycle*, below |
+
+**The three fields above answer three different questions, and one entry rarely needs all
+three.** `importPath` answers "where does this come from" without a read at all. `examples`
+answers "how is this called" — a worked example states the whole call, where the same answer
+assembled from a type chain can cost several files, since a `…Params` type is often a `Pick<>`
+of a declaration elsewhere and no file states the resolved shape. `bundle` answers "what are
+the props, and which are optional". Pick the one you need; reading a page for a fact the entry
+already carries is the common way a lookup gets expensive.
+
+`importPath` is parsed from the page's own import fence, so it agrees with what the doc shows.
+It is absent where a doc shows no `@wix/patterns` import of its own — a guide, or a type that is
+documented but not exported (see *Lifecycle* on `unreachable`). The bundle index derives the
+same fact independently, from `package.json`'s exports map, and the build warns when the two
+disagree.
+
+**The index is keyed by Storybook title, which is not always the export.** `ExportTo.md`
+documents `ExportButton`; `ToolbarFilters` is the entry for `CollectionToolbarFilters`. That
+is what `symbols` is for — resolve a name against the keys *and* the aliases.
+
+**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
+entry without the field carries its own table.
+
+## A bundle stops where you stop writing code
+
+A bundle holds its own name's declaration plus every shape **you** would write by hand. It
+deliberately does not expand what the library hands back, so two kinds of one-line stub are
+answers rather than truncation.
+
+An empty body with a **"Produced by"** note means: call that hook to get one.
+
+```ts
+/**
+ * `TableState` — you receive this, you don't construct it.
+ * Produced by `useTableCollection()` (also `useAmbassadorTable()`, `useTableContext()`).
+ * Look `TableState` up in the bundle index for its own API.
+ */
+declare class TableState<T, F> {
+}
+```
+
+`<Table state={…}>` needs `useTableCollection()`, not `TableState`'s internals — but if you
+do need its members, it has its own entry, where the body is complete.
+
+A stub saying **"cut here because it has its own bundle"** means the same for a shape you do
+write: it was not copied in twice.
+
+Every bundle fits in a single read, and the index's `bytes` field says how large before you
+open one. So a bundle is never partially shown — anything that looks missing was cut
+deliberately, and both stubs name where it went.
+
+**And the index says where, before you open anything.** A stub names its destination, but
+only once you are already inside the file — so following the chain by hand costs one round
+trip per hop, and the hops are only visible one at a time. `readWith` is that same
+information in the index: the bundles this one stubs, with `readWithBytes` for what the set
+costs, the way `bytes` does for a single file.
+
+```json
+"Table": {
+  "file": "components/Table.d.ts",
+  "bytes": 5277,
+  "readWith": [
+    "types/CollectionTableBaseProps.d.ts",
+    "types/Filter.d.ts",
+    "types/TableState.d.ts"
+  ],
+  "readWithBytes": 31731
+}
+```
+
+Direct edges only — but every name in a `readWith` has its own entry here, carrying its own
+`readWith`, so **the full chain closes from this index alone, reading nothing.** Walk it to
+the depth your question needs and open that set in one parallel read. `Table`'s props, for
+instance: the chain through `CollectionTableBaseProps` reaches `ToolbarCollectionBaseProps`
+and `ToolbarBaseProps` (and is circular — `ToolbarBaseProps` re-stubs the first), which is
+four files and 68KB of the eighteen-file, 145KB closure. Resolving that here is why the
+field is not the closure itself: "batch all eighteen" trades a waterfall for a context
+flood.
+
+An entry with no `readWith` is self-contained; `file` is the whole answer.
+
+## Types the docs do not cover
+
+The bundles also hold the types those props are built from — `Filter<T>`, `RangeItem<T>`,
+`OffsetQuery`, a `…Props` interface. Several are declared in `@wix/bex-core`; the bundle
+resolves and inlines the real declaration, so the full shape is there with no deep
+`@wix/bex-core/dist/types/…` path to chase. Import them from `@wix/patterns` regardless of
+where the bundle shows them declared.
+
+## A bare import is the one shape that does not say where to look
+
+A plain `import { X } from '<module>'` with no note attached means the bundle recorded where
+a type is *declared* rather than where it is exported. What follows depends on the path:
+
+- **A normal entry point** — `react`, `react-hook-form`, `history`,
+  `@wix/design-system` — resolves the ordinary way.
+- **A deep internal path** — `@wix/design-system/dist/types/DropdownLayout` — is an upstream
+  defect. It is not a public entry point, and the name is often not re-exported from the
+  package root either, so there is no shorter import to substitute. Where the type is a prop
+  you fill in, use the shape the owning library documents; where it is a pass-through you
+  never construct, pass what the patterns doc shows or omit it, since these are optional.
+
+## Lifecycle
+
+`status` carries `"deprecated"`, and `statusMessage` names the replacement —
+`PrimaryPageButton` says *"Use `PrimaryActions` component instead."* Worth checking before
+committing to a name: a deprecated component still compiles and still renders, so nothing
+else in the lookup path will stop you. The doc itself also carries the notice, above the
+import example.
+
+A few names carry `"status": "unreachable"`, plus `"unexported": true` from **1.465.0** —
+the `…BaseProps` interfaces a component's props `extends`. Read them for the props they
+contribute; do not write an import for them.
+
+## Entry points
+
+`@wix/patterns` is 31 entry points, not one namespace, and `/form` re-exports
+`@wix/bex-core/form`. The `exports/` directory under `dist/dts-bundle/` holds one file per
+entry point, named after the subpath: the package root is
+`dist/dts-bundle/exports/index.d.ts`, `@wix/patterns/form` is
+`dist/dts-bundle/exports/form.d.ts`, and a nested one such as `@wix/patterns/testkit/backend`
+is `dist/dts-bundle/exports/testkit/backend.d.ts`.
+
+**Those files list only the curated names**, so they are not an inventory of the entry point:
+a subpath's real export surface can be larger, and a file holding nothing but a comment means
+no curated name lives there yet — not that the subpath does not exist. For the authoritative
+import line, read the doc of the name you want.
+
+**`/form` is where that gap is widest, so it is worth stating outright.** It is
+`export * from '@wix/bex-core/form'`, which is itself `export * from 'react-hook-form'`, so
+its real surface is react-hook-form's entire public API. The names the guides and examples
+write are curated and carry an `importPath` like anything else — `useForm`, `useController`,
+`Controller`, `ControllerProps`, `FieldValues`, `UseFormReturn`. The rest, `useWatch` and
+`useFieldArray` among them, import from `@wix/patterns/form` just the same while appearing in
+neither index, and react-hook-form's own docs are their reference. So a react-hook-form name
+is never unexported merely because the docs index has no page for it; none of them does.
+
+## Cross-references and examples
+
+Docs link to related names as Storybook URLs — `[TableState](./?path=/story/…--tablestate)`.
+Resolve the link text back to a file through `dist/docs/index.json`, the same way you found
+the first doc. There is no automatic multi-level expansion. Links to
+`https://www.docs.wixdesignsystem.com/` are the design system's, not this library's.
+
+Compound components have a doc per sub-part — `CollectionPage.md`,
+`CollectionPage.Header.md`, `CollectionPage.Content.md`.
+
+Heavy examples are written beside the doc rather than inlined. The doc keeps the heading and
+the description and names the path: `Example code: read \`dist/docs/ToolbarFilters/apply-changes.tsx\``.
+The same files are listed in the entry's `examples` field.
+
+

package/dist/docs/RequestId.md

@@ -2,6 +2,8 @@
 
 **Category:** Features/Display/Errors/RequestId
 
+Examples below are illustrative: each one demonstrates this page's API, and everything around it — data source, layout, http client — is only scaffolding to make that runnable.
+
 ## Design
 
 ### Description

package/dist/docs/SecondaryActions.md

@@ -4,6 +4,8 @@
 
 Paths written as `dist/…` below are relative to the `@wix/patterns` package root — the directory holding its `package.json`.
 
+Examples below are illustrative: each one demonstrates this page's API, and everything around it — data source, layout, http client — is only scaffolding to make that runnable.
+
 ## Design
 
 ### Description

package/dist/docs/SettingsPage.AdditionalContent.md

@@ -2,6 +2,8 @@
 
 **Category:** Base Components/Pages/Settings Page
 
+Examples below are illustrative: each one demonstrates this page's API, and everything around it — data source, layout, http client — is only scaffolding to make that runnable.
+
 ## API
 
 ### Overview

package/dist/docs/SettingsPage.Card.md

@@ -2,6 +2,8 @@
 
 **Category:** Base Components/Pages/Settings Page
 
+Examples below are illustrative: each one demonstrates this page's API, and everything around it — data source, layout, http client — is only scaffolding to make that runnable.
+
 ## Examples
 
 ### Basic

package/dist/docs/SettingsPage.Content.md

@@ -2,6 +2,8 @@
 
 **Category:** Base Components/Pages/Settings Page
 
+Examples below are illustrative: each one demonstrates this page's API, and everything around it — data source, layout, http client — is only scaffolding to make that runnable.
+
 ## API
 
 ### Overview

package/dist/docs/SettingsPage.Header.md

@@ -2,6 +2,10 @@
 
 **Category:** Base Components/Pages/Settings Page
 
+Examples below are illustrative: each one demonstrates this page's API, and everything around it — data source, layout, http client — is only scaffolding to make that runnable.
+
+Some of that scaffolding is environment-scoped and is **not** needed to use this component: `@wix/ambassador-cairo-dummyservice-v1-dummy-entity/types`. Those resolve only against a Wix build environment (a Yoshi flow's runtime, a generated service client, an internal sibling package) — substitute your own data source and http client rather than installing them.
+
 ## Examples
 
 ### Basic

package/dist/docs/SettingsPage.MainContent.md

@@ -2,6 +2,8 @@
 
 **Category:** Base Components/Pages/Settings Page
 
+Examples below are illustrative: each one demonstrates this page's API, and everything around it — data source, layout, http client — is only scaffolding to make that runnable.
+
 ## API
 
 ### Overview

package/dist/docs/SettingsPage.md

@@ -4,6 +4,8 @@
 
 Paths written as `dist/…` below are relative to the `@wix/patterns` package root — the directory holding its `package.json`.
 
+Examples below are illustrative: each one demonstrates this page's API, and everything around it — data source, layout, http client — is only scaffolding to make that runnable.
+
 ## Overview
 
 ### Introduction
@@ -31,7 +33,7 @@ In summary, the ``SettingsPage`` component and the associated [`useSettingsPage`
 
 This example demonstrates a basic usage of the `SettingsPage`.
 
-Example code: read `dist/docs/SettingsPage/basic.tsx`
+Example code: read `dist/examples/SettingsPage/basic.tsx`
 
 ---
 
@@ -39,7 +41,7 @@ Example code: read `dist/docs/SettingsPage/basic.tsx`
 
 This example illustrates the use of both main and additional content.
 
-Example code: read `dist/docs/SettingsPage/2-columns.tsx`
+Example code: read `dist/examples/SettingsPage/2-columns.tsx`
 
 ---
 
@@ -47,7 +49,7 @@ Example code: read `dist/docs/SettingsPage/2-columns.tsx`
 
 This sample illustrates the skeleton state of an settings page based on the provided structure.
 
-Example code: read `dist/docs/SettingsPage/loading.tsx`
+Example code: read `dist/examples/SettingsPage/loading.tsx`
 
 ---
 
@@ -55,7 +57,7 @@ Example code: read `dist/docs/SettingsPage/loading.tsx`
 
 This example demonstrates the error state when fetching an settings fails.
 
-Example code: read `dist/docs/SettingsPage/error-on-fetch.tsx`
+Example code: read `dist/examples/SettingsPage/error-on-fetch.tsx`
 
 ---
 
@@ -63,7 +65,7 @@ Example code: read `dist/docs/SettingsPage/error-on-fetch.tsx`
 
 This example demonstrates the error toast when saving an settings fails.
 
-Example code: read `dist/docs/SettingsPage/error-on-save.tsx`
+Example code: read `dist/examples/SettingsPage/error-on-save.tsx`
 
 ---
 
@@ -73,7 +75,7 @@ Example code: read `dist/docs/SettingsPage/error-on-save.tsx`
 
 This demonstrates how to use [useController](https://react-hook-form.com/docs/usecontroller) with the default value set at the `Card.Content` level. Note that the `state.settings` value is initialized following the Card skeleton loader. To obtain the initial value, it must be accessed within the Card.Content child, as illustrated in the following example. Accessing it before or at a higher level will result in an `undefined` value.
 
-Example code: read `dist/docs/SettingsPage/input-initialization-with-usecontroller.tsx`
+Example code: read `dist/examples/SettingsPage/input-initialization-with-usecontroller.tsx`
 
 ---
 
@@ -81,7 +83,7 @@ Example code: read `dist/docs/SettingsPage/input-initialization-with-usecontroll
 
 This demonstrates how to use [Controller](https://react-hook-form.com/docs/usecontroller/controller) where you can easily access the settings by using `useSettings`. This method allows for accessing the settings much earlier in the process. As a result, the default value will be dynamically updated as soon as the settings itself is updated, as shown in the example below.
 
-Example code: read `dist/docs/SettingsPage/input-initialization-with-controller.tsx`
+Example code: read `dist/examples/SettingsPage/input-initialization-with-controller.tsx`
 
 ## API
 

package/dist/docs/SettingsPageState.md

@@ -2,6 +2,8 @@
 
 **Category:** Base Components/Pages/Settings Page/State
 
+Examples below are illustrative: each one demonstrates this page's API, and everything around it — data source, layout, http client — is only scaffolding to make that runnable.
+
 ## API
 
 ### Overview

package/dist/docs/SingleSelectFilter.md

@@ -4,6 +4,10 @@
 
 Paths written as `dist/…` below are relative to the `@wix/patterns` package root — the directory holding its `package.json`.
 
+Examples below are illustrative: each one demonstrates this page's API, and everything around it — data source, layout, http client — is only scaffolding to make that runnable.
+
+Some of that scaffolding is environment-scoped and is **not** needed to use this component: `@wix/yoshi-flow-bm`. Those resolve only against a Wix build environment (a Yoshi flow's runtime, a generated service client, an internal sibling package) — substitute your own data source and http client rather than installing them.
+
 ## Design
 
 ### Overview
@@ -26,25 +30,25 @@ import { SingleSelectFilter } from '@wix/patterns';
 
 ### Server Data
 
-Example code: read `dist/docs/SingleSelectFilter/server-data.tsx`
+Example code: read `dist/examples/SingleSelectFilter/server-data.tsx`
 
 ### Static Data
 
-Example code: read `dist/docs/SingleSelectFilter/static-data.tsx`
+Example code: read `dist/examples/SingleSelectFilter/static-data.tsx`
 
 ### Empty State
 
-Example code: read `dist/docs/SingleSelectFilter/empty-state.tsx`
+Example code: read `dist/examples/SingleSelectFilter/empty-state.tsx`
 
 ### Sections
 
-Example code: read `dist/docs/SingleSelectFilter/sections.tsx`
+Example code: read `dist/examples/SingleSelectFilter/sections.tsx`
 
 ### Custom render items
 
 The default behavior uses the itemName for rendering the option value. Use renderItem to override it.
 
-Example code: read `dist/docs/SingleSelectFilter/custom-render-items.tsx`
+Example code: read `dist/examples/SingleSelectFilter/custom-render-items.tsx`
 
 ## API
 

package/dist/docs/Sled Tests.md

@@ -2,6 +2,10 @@
 
 **Category:** Guides/Sled Tests
 
+Examples below are illustrative: each one demonstrates this page's API, and everything around it — data source, layout, http client — is only scaffolding to make that runnable.
+
+Some of that scaffolding is environment-scoped and is **not** needed to use this component: `@wix/yoshi-flow-bm/sled`. Those resolve only against a Wix build environment (a Yoshi flow's runtime, a generated service client, an internal sibling package) — substitute your own data source and http client rather than installing them.
+
 ## Design
 
 ### Overview

package/dist/docs/Sortable Columns.md

@@ -4,6 +4,8 @@
 
 Paths written as `dist/…` below are relative to the `@wix/patterns` package root — the directory holding its `package.json`.
 
+Examples below are illustrative: each one demonstrates this page's API, and everything around it — data source, layout, http client — is only scaffolding to make that runnable.
+
 ## Design
 
 ### Description
@@ -32,13 +34,13 @@ The [`query`](./?path=/story/common-types--computedquery) argument passed to [`f
 
 The **Name** column is defined as sortable in the relevant object in the `columns` array.
 
-Example code: read `dist/docs/Sortable Columns/basic-sortable-column.tsx`
+Example code: read `dist/examples/Sortable Columns/basic-sortable-column.tsx`
 
 ### Custom sort order
 
 Use the `sortMode` property in each columns object in the `columns` array to define the order of the sort options for that column.
 
-Example code: read `dist/docs/Sortable Columns/custom-sort-order.tsx`
+Example code: read `dist/examples/Sortable Columns/custom-sort-order.tsx`
 
 ## BI
 

package/dist/docs/Suggestions.md

@@ -4,6 +4,8 @@
 
 Paths written as `dist/…` below are relative to the `@wix/patterns` package root — the directory holding its `package.json`.
 
+Examples below are illustrative: each one demonstrates this page's API, and everything around it — data source, layout, http client — is only scaffolding to make that runnable.
+
 ## Design
 
 ### Description
@@ -45,7 +47,7 @@ export default Basic;
 
 Use `renderMarketingCard(transformFn)` when your offer data has a different structure and needs to be transformed into the `MarketingCardSchema` format.
 
-Example code: read `dist/docs/Suggestions/with-transform-function.tsx`
+Example code: read `dist/examples/Suggestions/with-transform-function.tsx`
 
 ---
 
@@ -53,7 +55,7 @@ Example code: read `dist/docs/Suggestions/with-transform-function.tsx`
 
 Provide a custom `renderCard` function for complete control over the card's appearance and behavior.
 
-Example code: read `dist/docs/Suggestions/custom-card-rendering.tsx`
+Example code: read `dist/examples/Suggestions/custom-card-rendering.tsx`
 
 ---
 
@@ -61,7 +63,7 @@ Example code: read `dist/docs/Suggestions/custom-card-rendering.tsx`
 
 When the number of offers exceeds `maxInlineItems`, the component switches from a fixed container layout (Box) to carousel layout. This example shows the same 3 offers rendered with different `maxInlineItems` values.
 
-Example code: read `dist/docs/Suggestions/carousel-vs-container-layout.tsx`
+Example code: read `dist/examples/Suggestions/carousel-vs-container-layout.tsx`
 
 ---
 
@@ -69,7 +71,7 @@ Example code: read `dist/docs/Suggestions/carousel-vs-container-layout.tsx`
 
 Use `carouselProps` to customize the carousel behavior. See the full [Carousel documentation](https://www.wix-pages.com/wix-design-system-employees/?path=/story/components-media--carousel) for all available options.
 
-Example code: read `dist/docs/Suggestions/carousel-customization.tsx`
+Example code: read `dist/examples/Suggestions/carousel-customization.tsx`
 
 ## API
 

package/dist/docs/SummaryBar.md

@@ -4,6 +4,8 @@
 
 Paths written as `dist/…` below are relative to the `@wix/patterns` package root — the directory holding its `package.json`.
 
+Examples below are illustrative: each one demonstrates this page's API, and everything around it — data source, layout, http client — is only scaffolding to make that runnable.
+
 ## Design
 
 ### Description
@@ -16,7 +18,7 @@ This data is not updated dynamically as part of a collection's fetch, meaning yo
 
 This example shows the summary bar in the `"success"` state using the `<SummaryBar>` `status` prop.
 
-Example code: read `dist/docs/SummaryBar/success.tsx`
+Example code: read `dist/examples/SummaryBar/success.tsx`
 
 ---
 
@@ -24,7 +26,7 @@ Example code: read `dist/docs/SummaryBar/success.tsx`
 
 This example shows the summary bar in the `"loading"` state using the `<SummaryBar>` `status` prop.
 
-Example code: read `dist/docs/SummaryBar/loading.tsx`
+Example code: read `dist/examples/SummaryBar/loading.tsx`
 
 ---
 
@@ -32,7 +34,7 @@ Example code: read `dist/docs/SummaryBar/loading.tsx`
 
 This example shows the summary bar in the `"error"` state using the `<SummaryBar>` `status` prop.
 
-Example code: read `dist/docs/SummaryBar/error.tsx`
+Example code: read `dist/examples/SummaryBar/error.tsx`
 
 ---
 
@@ -40,7 +42,7 @@ Example code: read `dist/docs/SummaryBar/error.tsx`
 
 This example shows the summary bar in the `"loading"` state, that changes to the `"success"` state when the data is fetched, using the `<SummaryBar>` `status` prop.
 
-Example code: read `dist/docs/SummaryBar/loading-with-success.tsx`
+Example code: read `dist/examples/SummaryBar/loading-with-success.tsx`
 
 ---
 
@@ -49,7 +51,7 @@ Example code: read `dist/docs/SummaryBar/loading-with-success.tsx`
 This example shows the summary bar in the `"loading"` state, that changes to the `"error"` state when the data fetch fails, using the `<SummaryBar>` `status` prop.
 The `onRetry` prop is used to retry the fetch the data when **Reload** is clicked.
 
-Example code: read `dist/docs/SummaryBar/loading-with-error.tsx`
+Example code: read `dist/examples/SummaryBar/loading-with-error.tsx`
 
 ## API
 

package/dist/docs/Table Sections.md

@@ -4,6 +4,8 @@
 
 Paths written as `dist/…` below are relative to the `@wix/patterns` package root — the directory holding its `package.json`.
 
+Examples below are illustrative: each one demonstrates this page's API, and everything around it — data source, layout, http client — is only scaffolding to make that runnable.
+
 ## Design
 
 ### Description
@@ -24,23 +26,23 @@ import { TableSections } from '@wix/patterns';
 
 This example sorts and groups the data by `jobTitle`.
 
-Example code: read `dist/docs/Table Sections/demo.tsx`
+Example code: read `dist/examples/Table Sections/demo.tsx`
 
 ### With Badge
 
 This example shows how to use a badge in the section header.
 
-Example code: read `dist/docs/Table Sections/with-badge.tsx`
+Example code: read `dist/examples/Table Sections/with-badge.tsx`
 
 ### With Summary
 
 This example shows how to use a summary in the section header.
 
-Example code: read `dist/docs/Table Sections/with-summary.tsx`
+Example code: read `dist/examples/Table Sections/with-summary.tsx`
 
 ### With Collapse
 
 This example shows how to use a collapse action in the section header.
 
-Example code: read `dist/docs/Table Sections/with-collapse.tsx`
+Example code: read `dist/examples/Table Sections/with-collapse.tsx`
 

package/dist/docs/Table.md

@@ -4,6 +4,10 @@
 
 Paths written as `dist/…` below are relative to the `@wix/patterns` package root — the directory holding its `package.json`.
 
+Examples below are illustrative: each one demonstrates this page's API, and everything around it — data source, layout, http client — is only scaffolding to make that runnable.
+
+Some of that scaffolding is environment-scoped and is **not** needed to use this component: `@wix/ambassador-ecom-v1-order/crud/http`, `@wix/yoshi-flow-bm`. Those resolve only against a Wix build environment (a Yoshi flow's runtime, a generated service client, an internal sibling package) — substitute your own data source and http client rather than installing them.
+
 ## Import
 
 ```tsx
@@ -33,39 +37,39 @@ import { Table } from '@wix/patterns';
 
 ### Basic table
 
-A basic table. Contains a search bar in the table's toolbar by default. To remove the search bar from the table's toolbar, set the `collectionSearch` prop to `false`.
+A basic table. Contains a search bar in the table's toolbar by default. To remove the search bar from the table's toolbar, set the `search` prop to `false`.
 
-Example code: read `dist/docs/Table/basic-table.tsx`
+Example code: read `dist/examples/Table/basic-table.tsx`
 
 ### Horizontal scroll
 
 Enabling horizontal scrolling within rows.
 
-Example code: read `dist/docs/Table/horizontal-scroll.tsx`
+Example code: read `dist/examples/Table/horizontal-scroll.tsx`
 
 ### Filters
 
 A table with filters. Use the `filters` prop to add filter capabilities to the table's toolbar.
 
-Example code: read `dist/docs/Table/filters.tsx`
+Example code: read `dist/examples/Table/filters.tsx`
 
 ### Cursor Pagination
 
 The default pagination is offset but you can change by providing cursor to `paginationMode` property.
 
-Example code: read `dist/docs/Table/cursor-pagination.tsx`
+Example code: read `dist/examples/Table/cursor-pagination.tsx`
 
 ### Header
 
-A table with a header row. Set the `titleBarDisplay` prop to `false` to hide the table header row.
+A table with a header row. Set the `showTitleBar` prop to `false` to hide the table header row.
 
-Example code: read `dist/docs/Table/header.tsx`
+Example code: read `dist/examples/Table/header.tsx`
 
 ### Table disabled rows
 
 set `selectionDisabled` to disabled rows.
 
-Example code: read `dist/docs/Table/table-disabled-rows.tsx`
+Example code: read `dist/examples/Table/table-disabled-rows.tsx`
 
 ---
 
@@ -75,7 +79,7 @@ The `TableVirtual` component is an extension of the `Table` component, designed
 
 It is recommended to use the `rowHeight` prop when the row heights are consistent across the table, and the `estimatedRowHeight` prop when the row heights are variable. Providing the correct props helps to optimize the virtualized rendering process.
 
-Example code: read `dist/docs/Table/virtual.tsx`
+Example code: read `dist/examples/Table/virtual.tsx`
 
 ---
 
@@ -83,7 +87,7 @@ Example code: read `dist/docs/Table/virtual.tsx`
 
 Use the `fetchTotal` prop to retrieve the total number of items in the collection. This example demonstrates how to use the `fetchTotal` prop asynchronously.
 
-Example code: read `dist/docs/Table/fetch-total-async.tsx`
+Example code: read `dist/examples/Table/fetch-total-async.tsx`
 
 ---
 
@@ -93,7 +97,7 @@ Example code: read `dist/docs/Table/fetch-total-async.tsx`
 
 If you have a crud package from ambassador you can use our [useAmbassadorCollection](./?path=/story/common-hooks--useambassadorcollection) hook instead using the default [useCollection](./?path=/story/common-hooks--usecollection).
 
-Example code: read `dist/docs/Table/using-ambassador.tsx`
+Example code: read `dist/examples/Table/using-ambassador.tsx`
 
 ### Using with External Data Source
 
@@ -101,7 +105,7 @@ This example demonstrates how to use the `fetchData` API when data already exist
 
  Note: Ensure that you use the query filter parameters, such as search and limit, to filter the data correctly.
 
-Example code: read `dist/docs/Table/using-with-external-data-source.tsx`
+Example code: read `dist/examples/Table/using-with-external-data-source.tsx`
 
 ## API