@wix/agent-skills 1.16.2 → 1.17.0

package/skills/wix-app/references/editor-react-component/COMPONENT-API.md

@@ -1,484 +0,0 @@
-# Component API
-
-Rules and patterns for props structure, elementProps, data types, file structure, containers, data-driven components, and array props.
-
----
-
-## Should This Use elementProps or CSS?
-
-```
-Is this element a named part (carries a global class string)?
-│
-├─ YES
-│   └─ ✅ It gets an elementProps entry — spread it + merge its className.
-│         Add config fields inside the entry only as needed
-│         (data, direction, event handlers).
-│
-└─ NO → purely visual/decorative non-part
-        (icons, separators, decorations, layout wrappers,
-         elements only hidden/shown via CSS)
-    └─ ❌ CSS class only — no elementProps entry
-```
-
----
-
-## Rules
-
-### Component Props Structure
-
-```typescript
-interface ComponentProps {
-  // Identity
-  id?: string;
-  className?: string;
-
-  // Mandatory features (from @wix/editor-react-types)
-  direction?: Direction;
-  a11y?: A11y; // ALL ARIA attributes come through this (ariaLabel, role, etc.)
-
-  // Component-specific props (NO children unless container-type - see container rules below)
-  label?: string;
-  items?: Array<ItemType>;
-  // ... from specification
-  // NEVER add: ariaLabel, ariaDescribedBy, role, etc. - use a11y prop instead
-
-  // Sub-component configuration (only if needed - see elementProps rules)
-  elementProps?: {
-    [partName]?: {
-      [configProp]?: string | boolean | number; // Only include if element needs config beyond className
-      direction?: Direction;
-    };
-  };
-}
-```
-
-### Propagate `elementProps` to inner elements
-
-`elementProps` is a map keyed by the manifest's inner-element keys; each entry
-carries that element's `className` (the editor sets it — this is how design
-states reach the element) plus any data.
-
-**Every named inner element — every element that carries a global class
-string — gets an `elementProps` entry, and you spread that entry onto the
-element.** This is mandatory, even when the element needs no other config:
-without it the editor cannot style that element or drive its states.
-
-How `className` gets merged depends on what the element is:
-
-- **Raw HTML element** (`<button>`, `<li>`, `<div>`): merge
-  `elementProps?.<key>.className` inline, alongside the global string and module
-  class — there's no component to do it.
-- **Sub-component built with this skill** (`<Inner/>`): the spread alone is
-  enough. `className` rides along inside it, and the sub-component merges it onto
-  its own root (every skill component merges its incoming `className`). Don't
-  merge it again at the call site.
-
-```tsx
-interface PlanCardProps {
-  className?: string;
-  elementProps?: {
-    cta?: { className?: string; href?: string };
-  };
-}
-
-// Raw HTML element — spread + merge className inline.
-// Note: the elementProps key is the short part name (`cta`), while the global
-// class is prefixed with the component name (`plan-card-cta`). Keep them as-is.
-<button {...elementProps?.cta} className={classNames('plan-card-cta', styles.cta, elementProps?.cta?.className)}>
-  {label}
-</button>
-
-// Sub-component built with this skill — spread is enough (it merges className itself):
-<PlanRow {...elementProps?.planRow} />
-```
-
-**Non-parts** (module-class-only elements: icons, decorations, separators,
-layout wrappers — no global class) get no entry. Style them with CSS.
-
-**Inside each entry**, add only the config the element needs (data, direction,
-event handlers). Never add a bare `className?` as the *only* field to decide
-whether an element qualifies — `className` always flows through; the entry
-exists because the element is a named part.
-
-### What Qualifies as a Part
-
-See [`PARTS.md`](PARTS.md) for root election (Step 0), the mandatory filter, and full rules. The root gets no `elementProps` entry — its `className`, `a11y`, and `direction` arrive as top-level props.
-
-### Derived values are not props
-
-If a displayed value can be computed with a simple pure function from
-other props and/or internal state, compute it internally — don't
-expose it as a prop. Expose only the source inputs (use numeric types
-when arithmetic is needed: `price: number`, not `price: string`).
-
-**Example:** subtotal = `price × quantity` → computed inside the component, not a prop.
-
-### Data-Driven Components (NO children in exported props)
-
-- Component's **exported interface** must NOT accept `children` prop
-- ALL content MUST come through explicit named props (see "Derived values" above for what stays internal):
-  - Text (labels, placeholders, messages) → `label`, `text`, `placeholder`, etc.
-  - Media (images, videos, icons) → `imageSrc`, `videoUrl`, `iconName`, etc.
-  - Links (URLs, hrefs) → `link`, `href`, `url`, etc.
-  - Collections (list items, options, menu items) → `items`, `options`, `menuItems`, etc.
-- **Internal implementation** can use children for composition between sub-components
-- Hardcoded values are ONLY for fallback defaults when props are undefined
-
-**Exception — Container-type components:** Components whose purpose is to wrap arbitrary child elements (e.g., BoxContainer) MAY accept `children: React.ReactNode`. This applies only to structural containers — data-driven leaf components (Button, Tabs, Accordion, etc.) must NOT use `children`.
-
-### Array Props: Data on Parent Only
-
-When the parent component defines an array prop (e.g., `items`), child/item components receive a single item directly. They do NOT redeclare the data structure in their own props.
-
-### Array Element Types: Always Objects with Named Keys
-
-Array elements MUST be objects with named keys. This enables stable item identity (each item can carry its own `id`/`key`), non-breaking extension (new fields can be added later without changing the prop signature), and semantic naming (each value has meaning instead of being an opaque scalar).
-
-**Allowed forms:**
-
-- Inline object literal: `Array<{ key: ValueType, ... }>`
-- Named interface where the interface itself is an object with named keys (e.g. `Array<AccordionItem>` is OK because `AccordionItem` is `{ name, content }`)
-
-**Never allowed as the array element:**
-
-- Primitives: `Array<string>`, `Array<number>`, `Array<boolean>`
-- Leaf data types from `@wix/editor-react-types`: `Array<Image>`, `Array<Link>`, `Array<Video>`, `Array<Audio>`, `Array<VectorArt>`, `Array<RichText>`. Wrap them in an object instead.
-- Nested arrays:  `Array<Array<{cover: image, caption: string}>>` `Array<{items: Array<image>, caption: string}>`
-
-**❌ Wrong:**
-
-```typescript
-tags: Array<string>;
-prices: Array<number>;
-flags: Array<boolean>;
-images: Array<Image>;
-links: Array<Link>;
-nestedArrays: Array<Array<any>>
-```
-
-**✅ Correct:**
-
-```typescript
-tags: Array<{ label: string }>;
-prices: Array<{ amount: number }>;
-flags: Array<{ enabled: boolean }>;
-gallery: Array<{ image: Image, caption?: string }>;
-links: Array<{ link: Link, label: string }>;
-items: Array<AccordionItem>; // AccordionItem is { name, content }
-```
-
-### Container Components (Blackbox Content)
-
-When a component specification indicates a "container" or "slot" area where users can add nested content, use `React.ReactNode` for that content prop.
-
-**When to use `React.ReactNode` for a content prop:**
-
-- The specification describes a "container" or "content area"
-- Users should be able to add arbitrary nested components
-- The component doesn't control what goes inside that area
-
-**RTL Support:** Elements that render `React.ReactNode` content MUST have `dir="ltr"` to prevent RTL inheritance from the parent component. See [`DIRECTIONALITY.md`](DIRECTIONALITY.md).
-
-### Component Data Types
-
-When creating TypeScript interfaces for component props, use types from `@wix/editor-react-types` for more complex types, to see the allowed type from this library, look at the following file `node_modules/@wix/react-component-schema/dist/editor-react-types.d.ts`:
-
-```typescript
-import type { Link } from "@wix/editor-react-types"; // Reference at node_modules/@wix/react-component-schema/dist/editor-react-types.d.ts
-```
-
-For **function event handler props** (`onClick`, `onDblClick`, `onChange`, `onFocus`, `onBlur`, `onMouseIn`, `onMouseOut`) and custom callbacks, follow [`FUNCTION-HANDLERS.md`](FUNCTION-HANDLERS.md). Key rules:
-
-- Use the exact SDK prop names from that file — the manifest system recognizes them
-- Wire them to the correct DOM events (note: `onDblClick` → `onDoubleClick`, `onMouseIn` → `onMouseEnter`, `onMouseOut` → `onMouseLeave`)
-- Custom callbacks not tied to DOM events use `() => void` (no React event parameter)
-
-### External resources are forbidden
-
-All resources rendered or fetched by the component (images, icons, fonts,
-videos, audio, JSON data, etc.) MUST come from Wix services. Never reference
-or call external (non-Wix) hosts — no `unsplash.com`, `placehold.co`,
-`picsum.photos`, third-party CDN icon sets, or any custom backend the user
-hasn't asked for. This rule covers both `src`/`href` attributes and any
-runtime fetching.
-
-Allowed image hosts: `static.wixstatic.com` (and other `*.wixstatic.com`
-subdomains). Allowed data: values supplied through props (populated by the
-editor) or imported local assets bundled with the component.
-
-### Default values for `Image` props
-
-Image defaults belong in the `<componentName>.props.ts` file's exported
-`defaultProps` constant (consumed by `withDefaults(Component, defaultProps)` in
-`component.tsx`). Use a Wix-hosted image from the Free-from-Wix public
-media catalog and populate **only** `uri`, `url`, and `alt` — leave
-`width`, `height`, `focalPoint`, etc. unset so the editor fills them when
-the user picks a real image.
-
-By default, use the canonical fallback URL from the examples below for
-every `Image` default (`url` and `uri` derived from the same `fileName`).
-**Only when the user explicitly asks for different/better default images**,
-fetch candidates from the Wix Free-from-Wix catalog:
-
-```
-GET https://publicmedia.wix.com/public/light_items?guid=bca5cb9f-45d2-4b11-8d6c-c9a7e7bd2873%3Aglobal%3Awix&pageSize=20&pageNumber=1&language=en&tags=free&mediaType=picture
-```
-
-The endpoint is unauthenticated. Pick an item whose `displayTags` /
-`title` fit the component's purpose, then build the `Image` default from
-its `fileName`:
-
-- `url` → `` `https://static.wixstatic.com/media/${fileName}` ``
-- `uri` → `fileName`
-- `alt` → a short human description (use the item's `title` or
-  `displayTags`)
-
-Do not call this endpoint when the user hasn't asked for it — the
-canonical fallback URL is fine for unattended scaffolds.
-
-**Default image pool — use a different image for each slot:**
-
-| # | fileName | Description |
-|---|----------|-------------|
-| 1 | `11062b_2f97b87dcea2446fa48e9ad9c5457ae1~mv2.jpg` | Tropical beach aerial |
-| 2 | `11062b_73f31c7e7d3544c69dc8ecd8d34c5717~mv2.jpg` | Dead Sea landscape |
-| 3 | `11062b_3682ebfcb08e4da5b3168b62819a1e68~mv2.jpg` | Palm tree sunset |
-| 4 | `11062b_45e67783d39c4963ab9e4fc418173233~mv2.jpg` | Abstract pink waves |
-| 5 | `11062b_4c11f014b0d04948b2e6f554076bc40a~mv2.jpg` | Coastal village aerial |
-
-When a component needs **more than one** image default, cycle through
-the pool above so every slot gets a visually distinct image. For a
-single image, use image #1.
-
-**Single `Image` prop:**
-
-```typescript
-export const defaultProps = {
-  image: {
-    url: "https://static.wixstatic.com/media/11062b_2f97b87dcea2446fa48e9ad9c5457ae1~mv2.jpg",
-    uri: "11062b_2f97b87dcea2446fa48e9ad9c5457ae1~mv2.jpg",
-    alt: "Default image",
-  },
-} as const satisfies Omit<ExampleComponentProps, "id" | "className">;
-```
-
-**Array of objects with an `Image` field:**
-
-```typescript
-export const defaultProps = {
-  cards: [
-    {
-      title: "First card",
-      image: {
-        url: "https://static.wixstatic.com/media/11062b_2f97b87dcea2446fa48e9ad9c5457ae1~mv2.jpg",
-        uri: "11062b_2f97b87dcea2446fa48e9ad9c5457ae1~mv2.jpg",
-        alt: "First card image",
-      },
-    },
-    {
-      title: "Second card",
-      image: {
-        url: "https://static.wixstatic.com/media/11062b_73f31c7e7d3544c69dc8ecd8d34c5717~mv2.jpg",
-        uri: "11062b_73f31c7e7d3544c69dc8ecd8d34c5717~mv2.jpg",
-        alt: "Second card image",
-      },
-    },
-  ],
-} as const satisfies Omit<ExampleComponentProps, "id" | "className">;
-```
-
-**Inline fallback for HTML `src` / `href`:** when rendering a raw HTML
-attribute that takes a URL (`<img src>`, `<source src>`, `<video poster>`,
-`<a href>` for an image link, etc.) and the value could be empty, fall
-back to the same Wix-hosted URL — never to an external host or a relative
-path that doesn't exist:
-
-```tsx
-<img
-  src={
-    image?.url ||
-    "https://static.wixstatic.com/media/11062b_2f97b87dcea2446fa48e9ad9c5457ae1~mv2.jpg"
-  }
-  alt={image?.alt || "Default image"}
-/>
-```
-
-### Component File Splitting
-
-Split logical UI pieces into separate named components. Never write inline JSX blocks for distinct complex UI pieces.
-
-**File structure for complex components (many subcomponents):**
-
-```
-ComponentName/
-├── components/                 # Subcomponents folder
-│   ├── SubComponent1/
-│   │   ├── SubComponent1.tsx
-│   │   ├── SubComponent1.module.scss
-│   │   └── index.ts
-│   └── SubComponent2/
-│       ├── SubComponent2.tsx
-│       └── index.ts
-├── hooks/                      # Custom hooks folder
-│   ├── index.ts
-│   └── useCustomHook.ts
-```
-
-**When to extract a sub-component:**
-
-- JSX block represents a logical complex unit (button, control, section, item)
-- Component has its own props interface
-- Logic is reusable or testable independently
-- Block has more than 15-20 lines of JSX
-
----
-
-## Patterns
-
-### Data-Driven Pattern
-
-**❌ Wrong:**
-
-```typescript
-export interface ButtonProps {
-  children: React.ReactNode;  // ❌
-}
-<Button>Click Me</Button>
-```
-
-**✅ Correct:**
-
-```typescript
-export interface ButtonProps {
-  label?: string;
-  icon?: string;
-}
-<Button label={label} icon={icon} />
-```
-
-Component controls rendering internally:
-
-```typescript
-const List = ({ items }) => (
-  <div>
-    {items.map(item => (
-      <ListItem key={item.id}>{item.label}</ListItem>
-    ))}
-  </div>
-);
-```
-
-### Array Props Pattern
-
-Parent defines array structure, child receives single item:
-
-```typescript
-// Parent
-interface ParentProps {
-  items: Array<AccordionItem>;  // Array defined here
-}
-
-interface AccordionItem {
-  name: string;
-  content: React.ReactNode;
-}
-
-// Child receives single item
-interface ChildProps {
-  item: AccordionItem & { id: string };  // Single item
-  isOpen?: boolean;
-}
-
-// Parent maps
-items.map((item, index) => (
-  <Child key={index} item={{ ...item, id: index.toString() }} />
-))
-```
-
-### Container Components Pattern
-
-For "container" or "slot" areas, use `React.ReactNode`:
-
-```typescript
-interface AccordionItem {
-  name: string;
-  content: React.ReactNode;  // Users add any content here
-}
-
-// Render
-{items.map((item, index) => (
-  <div key={index} dir="ltr">
-    {typeof item.content === 'function' ? item.content({}) : item.content}
-  </div>
-))}
-```
-
----
-
-## Common Mistakes
-
-### Using children prop in exported interface
-
-**❌ Wrong:**
-
-```typescript
-export interface CardProps {
-  children: React.ReactNode;  // ❌ children + React.ReactNode both forbidden
-}
-<Card><CardHeader>Title</CardHeader></Card>
-```
-
-**✅ Correct:**
-
-```typescript
-export interface CardProps {
-  title: string;
-  content: React.ReactNode;
-}
-<Card title="Title" content={<div>Content</div>} />
-```
-
-### Adding elementProps for CSS-only elements
-
-**❌ Wrong:**
-
-```typescript
-elementProps?: {
-  icon?: { className?: string; }  // ❌ Only className
-  separator?: { className?: string; }  // ❌ Only className
-}
-```
-
-**✅ Correct:**
-
-```typescript
-// No elementProps for purely visual elements (including conditionally displayed)
-// Style via CSS classes directly
-```
-
-**Why:** Don't declare a `className?:` field — `className` already flows through each named inner element's `elementProps` entry (see "Propagate `elementProps` to inner elements"). Conditional display is controlled via CSS, not React props.
-
-### Using T[] array syntax
-
-Use `Array<T>` over `T[]`.
-
-**❌ Wrong:**
-
-```typescript
-interface ComponentProps {
-  items: Item[]; // ❌ Wrong syntax
-  tags: string[]; // ❌ Wrong syntax
-  tags: Array<string>; // ❌ Element must be an object with named keys
-}
-```
-
-**✅ Correct:**
-
-```typescript
-interface ComponentProps {
-  items: Array<Item>; // ✅ Correct syntax
-  tags: Array<{ label: string }>; // ✅ Element is an object with named keys
-}
-```
-
-See also: [Array Element Types: Always Objects with Named Keys](#array-element-types-always-objects-with-named-keys) — items must be objects with named keys.

package/skills/wix-app/references/editor-react-component/COMPONENT-CONFIGURATION.md

@@ -1,225 +0,0 @@
-# Component Configuration
-
-After scaffolding the component and running `npx wix build && npx wix generate manifest`,
-configure the component's behavior in the editor by writing **partial
-manifest overrides** in the component's hand-edited extension file
-(`<ComponentName>.extension.ts`). That file imports the auto-generated
-manifest and spreads it; specific fields are overridden inline. Re-running
-this command regenerates each `<ComponentName>.generated.ts`
-companion but never touches the overrides authored in the extension file.
-
----
-
-## 1. Verifying that height sizing type meets user needs
-
-Set `installation.initialSize.height.sizingType` based on whether the
-component's own content decides how tall it is.
-
-### Heuristic — one question
-
-**Does the component's own content decide how tall it is?**
-
-- **Yes — height should grow with text the user types or children they drop inside** → `LAYOUT.SIZING_TYPE.content`. Omit `pixels`.
-- **No — the component is a framed visual** (a graphic, an embedded media surface, a form control with a standard height, an empty placeholder) → `LAYOUT.SIZING_TYPE.pixels`. Provide a `pixels` default that matches its natural visual size.
-
-**Tiebreaker:** if a designer would drag a handle to set the height, it's `pixels`. If the height should just fit whatever is inside, it's `content`.
-
-### Where to write the override
-
-```ts
-import { extensions } from '@wix/astro/builders';
-import { LAYOUT } from '@wix/react-component-schema';
-import { manifest } from './ComponentName.generated';
-
-const componentExtension = extensions.editorReactComponent({
-  // …other fields…
-  installation: {
-    initialSize: {
-      width: {
-        sizingType: LAYOUT.SIZING_TYPE.pixels,
-        pixels: 250,
-      },
-      height: {
-        sizingType: LAYOUT.SIZING_TYPE.updateMe,
-      },
-    },
-  },
-});
-```
-
-### Examples
-
-**Content-driven** (`LAYOUT.SIZING_TYPE.content`) — testimonial card,
-FAQ accordion, pricing tier, blog-post body, list/grid of arbitrary
-children:
-
-```ts
-height: {
-  sizingType: LAYOUT.SIZING_TYPE.content,
-}
-```
-
-**Framed visual** (`LAYOUT.SIZING_TYPE.pixels`) — hero banner with a
-fixed image, video embed, color-picker swatch grid, OTP input, empty
-placeholder slot:
-
-```ts
-height: {
-  sizingType: LAYOUT.SIZING_TYPE.pixels,
-  pixels: 320,
-}
-```
-
----
-
-## 2. Verifying that resize direction meets user needs
-
-Set `editorElement.layout.resizeDirection` based on which axes the
-designer should be able to control with a drag handle. Allow an axis
-if dragging it produces a meaningful, intended change. Disallow it if
-dragging would do nothing visible or would break the component's
-identity.
-
-### Heuristic — which axes are meaningful?
-
-| Choice | When to use |
-|--------|-------------|
-| `horizontalAndVertical` | Content fills or stretches in both axes. Hero, carousel, gallery, card grid, embed, form control, any framed visual. **Default for most components.** |
-| `horizontal` | Height is rigid/intrinsic — cannot meaningfully stretch. Breadcrumb, tag row, nav bar, single-line input, slider rail. |
-| `vertical` | Width is rigid/intrinsic. Vertical stack, ribbon, sidebar rail. |
-| `aspectRatio` | Distortion breaks identity — logo, illustration, animation. |
-| `none` | Size fully owned by a parent layout. Never for top-level components. |
-
-**Tiebreaker:** if a drag handle on an axis would feel inert or wrong
-to a designer, take it away.
-
-### Where to write the override
-
-```ts
-import { extensions } from '@wix/astro/builders';
-import { LAYOUT } from '@wix/react-component-schema';
-import { manifest } from './ComponentName.generated';
-
-const componentExtension = extensions.editorReactComponent({
-  // …other fields…
-  editorElement: {
-    ...manifest.editorElement,
-    layout: {
-      resizeDirection: LAYOUT.RESIZE_DIRECTION._selectedResizeDirection_,
-    },
-  },
-});
-```
-
-### Examples
-
-```ts
-// hero, carousel, gallery, card grid, embed, form
-resizeDirection: LAYOUT.RESIZE_DIRECTION.horizontalAndVertical,
-
-// breadcrumb, tag row, nav bar, slider rail
-resizeDirection: LAYOUT.RESIZE_DIRECTION.horizontal,
-
-// logo, illustration, animation
-resizeDirection: LAYOUT.RESIZE_DIRECTION.aspectRatio,
-```
-
----
-
-## 3. Wiring defaults into the manifest
-
-1. **Define and export `defaultProps` from `<componentName>.props.ts`** — this is the single source of truth used by both `component.tsx` and the extension file.
-2. **Import `componentUrl` from `'./component.tsx?url'`** (the wrapped component), not from `'./ComponentName.tsx?url'` (the raw component).
-3. **Wrap `editorElement` with `withEditorElementDefaults`** using the same `defaultProps`.
-
-```ts
-import { withEditorElementDefaults } from '@wix/react-component-utils';
-import componentUrl from './component.tsx?url';
-import { defaultProps } from './<componentName>.props';
-
-// in the extension:
-editorElement: withEditorElementDefaults({
-  ...manifest.editorElement,
-}, defaultProps),
-resources: {
-  ...manifest.resources,
-  client: { componentUrl },
-},
-```
-
----
-
-## 4. Enabling automatic installation on Harmony editor
-
-**Always include `"staticContainer": "HOMEPAGE"`** in `installation` so the
-component is automatically installed on the Harmony editor.
-
-```ts
-const componentExtension = extensions.editorReactComponent({
-  // …other fields…
-  installation: {
-    // …other fields…
-    staticContainer: 'HOMEPAGE',
-  },
-});
-```
-
----
-
-## 5. Adding range constraints for numeric props
-
-The zero-config pipeline reads `@min` and `@max` JSDoc tags on numeric props and
-emits them as `number: { min, max }` in the generated manifest. Add these tags
-directly on the prop in the component's props interface — no extension file
-override is needed.
-
-### Heuristic — does this number have a fixed domain?
-
-| Scenario | Action |
-|----------|--------|
-| Rating 0–5, column count 1–6, items per row 1–4 | Add `@min` / `@max` |
-| Volume 0–100, playback speed 0.5–5, autoplay delay 0.5–30 | Add `@min` / `@max` |
-| Geo coordinates, zoom level | Add `@min` / `@max` |
-| Arbitrary count, free-form price, unconstrained input | Omit — leave as `number` |
-| Semantic index (active tab, active slide, active item) | Omit — upper bound is driven by the component's own item count, not a fixed domain |
-
-### How to write the tags
-
-Add `@min` and `@max` inline in the JSDoc comment for the prop in `<componentName>.props.ts`:
-
-```ts
-export interface RatingWidgetProps {
-  /** @min 0 @max 5 */
-  rating: number;
-}
-```
-
-Zero-config picks these up during `npx wix build && npx wix generate manifest`
-and emits:
-
-```ts
-rating: {
-  dataType: 'number',
-  number: { min: '0', max: '5' },
-}
-```
-
-### Examples
-
-```ts
-// Star rating 0–5
-/** @min 0 @max 5 */
-rating: number;
-
-// Volume 0–100
-/** @min 0 @max 100 */
-volume: number;
-
-// Playback speed 0.5–5
-/** @min 0.5 @max 5 */
-speed: number;
-
-// Column count 1–6
-/** @min 1 @max 6 */
-columns: number;
-```