A Studio Two component rarely works alone. Its manifest lets it expose state to other components, consume state another component exposes, and nest inside or wrap other components. Components can also call functions bundled into a function library.
Components work together through patterns including:
The manifest examples in this article show only the fields each pattern relies on. A full manifest also has fields such as id, name, and resources. The type of each component you build starts with the site's code identifier, which is always companionApp in a Studio Two site. The site's wix.config.mjs sets the identifier, and Studio Two rejects a manifest for your own component whose type doesn't start with companionApp.. A type that names one of Wix's built-in elements, such as wix-basic-input in a refElement, keeps the identifier Wix gave it.
Editor binding creates a connection between a Data Source and an Editor React Component (ERC) through the Studio Two editor. Data Source is the Studio Two UI name for a context provider extension. Unlike direct React prop passing, the connection is configured by a Wix user and mediated by the context provider and ERC manifests.
Use this pattern when an ERC is generic enough that it shouldn't be tied to one specific context. A card component that displays a name, an image, and a description, for example, could bind to a team member context on one page and a product context on another. The Wix user decides which context feeds it, rather than the code assuming it in advance. To tie an ERC to one Wix business solution's context instead, see Use a Wix context in an ERC's code.
context.items.data section.The manifest for the team member Data Source exposes a name and a photo:
The card ERC's manifest declares the props it accepts:
Once name is bound to title and photo to image, the card receives them as ordinary props:
The context item and the ERC prop don't need matching names, since the Wix user is the one who connects them.
The same binding surface also connects a function-typed prop to a function from a function library, not just to a Data Source.
The context provider behind a Data Source stores state that several ERCs can share. Each ERC connects to the same Data Source through editor binding, even when the ERCs are otherwise unrelated. The ERCs don't pass props to one another or import the provider. Each one receives the values and functions it's connected to as ordinary props.
Use this pattern when several ERCs need the same state, such as a count and the buttons that change it.
context.items.Only ERCs nested inside that page, container, or section can connect to the Data Source.
The context provider manifest for a counter Data Source exposes a count and the functions that change it:
Three unrelated ERCs, a count display and two separate buttons, each declare just the prop they need:
Each ERC receives its connected value or function as a prop:
In the editor, a Wix user connects the count display's count prop to the count item, and each button's function prop to the matching function.
When a site visitor clicks either button, the button calls its connected function, and the provider updates the count. The count display receives the new value and renders again.
Many Wix business solutions provide React contexts that hold the solution's data and functionality. An ERC can use a Wix business solution context directly by calling the context's React hook in its own code. For example, the Stores Product Context holds a product's details, prices, and stock, the site visitor's selected options, and functions such as adding the selection to the cart. A business solution provides its context on some of its own pages, through a Data Source a Wix user attaches, such as the Product Data Source, or for each item in one of its lists.
Use this pattern when an ERC is built for one business solution and should adapt to wherever a Wix user places it, without the Wix user connecting each prop. A price display that reads the Product Context, for example, shows the price of whichever product the surrounding page, Data Source, or list item provides.
resources.A price display ERC reads the price and stock of the product its context provides:
Each context's reference lists the pages, Data Sources, and list items that provide it. Anywhere else, the context's hook throws an error.
In the editor, many Wix contexts fill empty values with sample content, so a Wix user designs with realistic data. Each context's reference describes its behavior in the editor.
Both patterns get values from a context or Data Source into an ERC. They differ in who decides the connection and what the ERC depends on:
| Editor binding | The context's hook | |
|---|---|---|
| Who chooses the source | The Wix user, in the editor | You, in the ERC's code |
| Where the ERC works | Anywhere, since it doesn't depend on a specific context | Only inside a page, Data Source, or list item that provides the context |
| What the ERC gets | Each item the Wix user connects, as a prop | Every property and function the context has |
| Which contexts | Any Data Source, Wix or custom | Wix business solution contexts |
For every Wix business solution context, its properties and functions, and where it's available, see Wix Business Solution Contexts. For the steps, see Use a Wix Context in an Editor React Component in Studio Two.
An ERC can declare container slots, where a Wix user drops other elements, including other ERCs, as children. The parent ERC receives what's in each slot as a prop and renders it, so components nest inside one another the way plain React components do.
Use this pattern when an ERC's job is to arrange other components rather than render all of its content itself. A collapsible section, for example, renders its own header and toggle, but it doesn't know or care what a Wix user puts in its body.
Two container types cover most ERCs:
container object sets containerType, and a selector that matches the element in the component that holds the slot.selector matches.In a Studio Two site, the container belongs with your manifest overrides in <component-folder>.extension.ts, which regenerating the manifest doesn't overwrite. For how overrides work, see Build an Editor React Component in Studio Two.
Set the data type and the container type with the DATA and CONTAINER_TYPE enums from @wix/react-component-schema. A plain string such as 'simple' fails type checking. Like every manifest selector, the slot's selector must match a plain string class, because CSS Modules rewrite module class names at build time.
The collapsible section ERC declares one slot for its body:
The component types the prop as Container from @wix/editor-react-types. A container arrives as either a React node or a function, so the component renders a node and calls a function. The prop has no default, because its content comes from the editor. The component hides the body with hidden instead of removing it, so the element that selector matches is always rendered:
A template container points to an array data item. Instead of a single value, the parent ERC receives a render function and calls it once per item in the array. A product grid, for example, doesn't know in advance how many products a Wix user's catalog has, so it needs a slot that repeats to fit the array.
The product grid ERC declares a products array and a template container tied to it:
The component receives renderProduct as a function that takes an item and its index. It renders each result inside an element with the slot's class:
For every container field, see Container Data Types and Container.
An ERC's manifest can use Wix's own built-in elements as part of its structure. A refElement in the manifest references an existing Wix element, like a button or an input, and inherits its behavior and definitions, which the developer can then override, for example to disable editing on a CSS property or change a display name.
Use this pattern when rebuilding a piece of UI from scratch would mean losing behavior that's worth keeping, like built-in validation or accessibility. A signup form ERC's email field, for example, is better off reusing Wix's input element than reimplementing email validation itself.
refElement entry referencing an existing Wix element.The signup form ERC's manifest references Wix's input element for its email field, keeping its built-in validation locked in place:
An Editor Function Library bundles reusable, stateless functions that a Wix user can connect to a slot in the editor, the same way they'd connect a context-exposed function. Its manifest declares each function's parameters and return type, the same way a context declares its items.
Use this pattern for utilities that many otherwise-unrelated components need to share, like currency formatting or a shared validation rule, where the state and lifecycle of a Data Source would be unnecessary overhead.
resources.client points to the bundle where those functions are implemented.A library of string utilities declares its functions like this:
context section of a context provider manifestLast updated: 2 November 2026