Editor React Component Extension Files and Code

When you add an Editor React Component (ERC) extension, the generated files land under src/extensions/site/components/<component-folder>/ and the extension is registered in your project's extensions.ts.

This file set is the same whether you add the ERC in a Studio Two site project or in a Wix CLI app.

Copy

The folder holds seven files. You edit five of them and leave two alone:

FileYou edit it?What it's for
<component-folder>.tsxYesThe component's UI logic and JSX. This is where you spend most of your time.
<component-folder>.props.tsYesThe component's props type and its defaultProps.
<component-folder>.module.cssYesThe component's styles, scoped as a CSS Module.
<component-folder>.extension.tsYesThe editable manifest: identity, installation, resources, and any overrides you apply to the generated editorElement.
component.preview.tsxYesHow the component renders in the editor. Its requiredDataFields list must name only props the component has.
component.tsxNoThe entry point that wires your component to its default props.
<component-folder>.generated.tsNoThe auto-generated editorElement. Overwritten the next time the manifest regenerates.

The manifest follows from the component rather than the other way around. You build the React component first. Wix tooling generates the editorElement portion from your component code, CSS, and prop types, and writes it to <component-folder>.generated.ts. You never edit that output directly. To change what's customizable, change the source files, or override the result in <component-folder>.extension.ts.

<component-folder>.extension.ts

This file is the editable manifest. It declares the component's identity, installation size, and resources, and it imports the auto-generated editorElement from <component-folder>.generated.ts. Don't delete it.

You own this file. Regeneration doesn't overwrite it.

Import extensions from the package your project uses:

Copy
Copy
Copy
  • withEditorElementDefaults() adds the values from defaultProps to the generated declarations, keeping the editor controls aligned with the rendered component.
  • deepmerge() layers your overrides on top without discarding generated data, elements, or CSS properties.
  • resources.client points to the live-site entry point.
  • resources.editor points to the editor entry point.

Don't change id after releasing the extension. The type also forms a durable contract with the editor. Review the manifest validation rules before changing an existing declaration.

For the full set of fields, see About the Editor React Component Manifest. For installation size and placement, see Installation. For client and editor URLs, see Resources.

<component-folder>.generated.ts

This file holds the auto-generated editorElement. That's the part of the manifest that declares editable data, inner elements, CSS properties, presets, states, and layout, so the editor can build matching auto panels.

Don't edit this file. Manual changes are overwritten the next time the manifest regenerates. Change the source files instead, or override specific fields in <component-folder>.extension.ts.

<component-folder>.tsx

This file is the React implementation. Import the props type from <component-folder>.props.ts, apply id and className to the root element, and give that root a class that matches the manifest selector.

The structure of your JSX, CSS classes, and prop types is what the generated editorElement is derived from. Pair a plain string class with your CSS Module class on every element the editor should be able to select. Use a module class alone for structural wrappers you don't want Wix users to select.

For the DOM contract, see Component Requirements. For the props the component receives, see Runtime Props Reference.

<component-folder>.props.ts

This file holds the props type and a defaultProps constant. Set each default once here. component.tsx applies those defaults when the component renders, and the editable manifest uses them so the editor panels open on the same values.

The prop names become data keys in the generated manifest, and their types determine which editor controls are available. Don't hand-write defaultValue into generated data items. Exclude id and className from defaultProps. Wix always provides those.

For the values the component receives, see Runtime Props Reference.

component.tsx

This file is the entry point the live site loads. It imports your component and defaultProps, then wires them together with withDefaults(). Don't change its structure. Write UI in <component-folder>.tsx and set defaults in <component-folder>.props.ts.

component.preview.tsx

This file is the entry point the editor loads. It renders the same component the live site uses, wrapped in withFallbackPlaceholder. The wrapper's requiredDataFields list names the scaffold's title and description props.

When a field in that list is missing from the component's props, the editor shows a placeholder instead of your component. So when you rename or replace props in <component-folder>.props.ts, update the list to name your content props. Don't add id or className, which Wix supplies.

Also edit this file when the component should behave or look different in the editor than on the live site, for example to supply mock data so the stage looks populated, or to disable an interaction that would get in the way of editing.

<component-folder>.module.css

This file holds default styles as a CSS Module, which scopes class names so they don't collide with other components on the page. Styled properties become candidates for controls in the Design panel.

Because those class names are scoped, they aren't the classes the manifest selector matches. Add a plain string class on the elements the editor targets, alongside the module class.

See also

Last updated: 2 November 2026

Did this help?