MANIFEST

A binding-only consumer never sees the provider source. It decides what to wire from displayName and description alone, so those fields carry the whole meaning of the value.

• displayName names the element and the state the value represents.
• description states exactly when the value is true, and — for items meant to be bound — which element surface to bind it to.
• Both are translatable free text — displayName max 100 chars, description max 300.

Extension Registration

The generated <provider-kebab-case-name>.extension.ts holds the manifest; fields are in CONTEXT_PROVIDER_SPEC.md.

Context Items

The context.items map defines what the provider exposes to child components. Each item requires a dataType. See CONTEXT_PROVIDER_SPEC.md for all ContextItem fields and constraints.

⚠️ CRITICAL: context vs data Array Format Difference

The context section and data section use different types for array items. Mixing them up causes the checkpoint error arrayItems is missing arrayItems.item or arrayItems.dataItem with dataType.

An array of objects follows the same rule in both sections: the object is the array element, so it goes under item (context) or dataItem (data) with dataType: 'data'. Never put data: { items } directly under arrayItems. Editor React Components accept that form, context providers reject it.

Context Item Shapes

Entries in context.items — functions, arrays, and enums (full type definitions in CONTEXT_PROVIDER_SPEC.md):

Context Implementor

Delegates part of the context to a separate component. Useful for item-level contexts with scoped functions (e.g., setAsCurrentItem). contextImplementor belongs in the context section (on a ContextItem or inside a nested ContextDataItems) — never in data.

The implementor component must be part of the same application and is rendered inside the parent’s tree, giving it access to the parent context.

Resources

componentType already exists (code 2018)

Component type '<type>' is already registered by another component (code 2018, componentType already exists). The platform’s background preview reports it. The type is built from name (<codeIdentifier>.<camelCaseName>) and is globally unique, so a second extension with the same name is rejected. Give the new extension a different name and type, and a different moduleSpecifier (never rename one that was already released).

Editor Binding

Context is consumed via Editor Binding: a native Editor element receives context data and methods as props, without importing the hook or having a direct dependency on the provider’s bundle. The editor UI lets the site owner connect an element’s props to a context provided by any component above it in the React tree. From the element’s perspective this is identical to receiving static props — it doesn’t know or care whether the values come from context or direct configuration.

A native, non-React Wix Editor element already on the stage — a built-in Heading, Text, Button, Image — consumes context by having the site owner connect a context item to one of the element’s surfaces:

One item, one surface, straight through — the value reaches the element unchanged apart from the platform’s automatic type conversion, with no expression layer in between. This is the constraint that governs what the provider must expose: see Derived Values and The Manifest Is the Binding Contract for how to describe each item so the right binding is chosen.

No consumer is written or registered for this path — the provider is the only code involved, and it is still registered exactly as always, hook export and contextSpecifier included. Plain text and number items connect to Wix’s built-in text elements with no additional setup — the platform converts them to rich text at the binding (see Plain Values, Not RichText Twins). A worked end-to-end example is in EXAMPLES.md.

Code Quality Requirements

The project-wide rules are in CODE_QUALITY.md. For a provider:

• Strict TypeScript with no any types
• Explicit return types for all functions
• Proper null/undefined handling with optional chaining
• Functional components with hooks
• SSR-safe code (no browser APIs at module scope)
• No @ts-ignore or @ts-expect-error comments, except the // @ts-ignore directly above an import of a context by its moduleSpecifier (see Importing a Context in Code)
• Use const/let (no var)