Editor React Component Extension Files and Code

When you add an Editor React Component extension to your CLI project, the CLI generates a component folder with the name you choose, containing the following files:

Which file does what

The folder holds 7 files. Most of your work happens in 3 of them, and 2 you never touch:

The 3 files at the top of the list are the ones the manifest is derived from. When you run wix generate manifest, the CLI reads your JSX, your prop types, and your CSS rules, and writes <component-name>.generated.ts from them. You never edit that output directly. To change the manifest, either change the source files and regenerate, or override the result in <component-name>.extension.ts.

Keeping the props type and defaultProps together in <component-name>.props.ts matters, because both <component-name>.tsx and component.tsx import from it. One shared file avoids a circular dependency between your component and the files that wire it up.

component-name.extension.ts

The <component-name>.extension.ts file defines your component's identity, installation behavior, and code resources. It also imports the auto-generated editorElement from <component-name>.generated.ts and combines it with the rest of the configuration. This file is required, so don't delete it after the component is generated. If you add your own files, you must include <component-name>.extension.ts.

You own this file and edit it manually. The CLI doesn't overwrite it when you regenerate the manifest.

When you generate a new Editor React Component in your project, <component-name>.extension.ts looks like this:

The generated configuration includes:

Installation options

The installation object controls how your component appears when a Wix user first adds it to a page. It works together with layout in editorElement: installation sets the starting size and placement, and layout controls how the Wix user can resize from there.

If you omit small, the desktop preset cascades to mobile. Setting small, or editing the component in the mobile view, breaks that cascade.

For the full set of installation properties, including fixedPosition for pinning a component to the page, and more examples, see Installation.

Translations

Component translations are JSON files you host with your component; the viewer loads the file that matches the site language at runtime. Declare them in resources.translations, and add the viewer-core/translations service dependency so your component can read the strings:

In <component-name>.tsx, look up keys with the translations service:

For the translation file format, the full property reference, and more examples, see Resources.

Overriding the generated manifest

Most of your editorElement comes from <component-name>.generated.ts, which you can't edit. <component-name>.extension.ts is where you change it, and the scaffold sets up 2 helpers to make that safe.

withEditorElementDefaults fills in the manifest's default values from your component's defaultProps:

This is why the editor panels open showing the same values your component renders, and why you set your defaults once in <component-name>.props.ts instead of writing defaultValue into every data item.

merge, from deepmerge, layers your own settings on top:

Use merge rather than assigning editorElement directly, so that adding a layout block doesn't discard the generated data, elements, and cssProperties underneath it.

Override only what the generator can't work out on its own, such as layout and installation. Anything derived from your component's code, CSS, or prop types belongs in the source files instead, so your change survives the next regeneration.

For comprehensive documentation on configuring your manifest, see About the Manifest and the Manifest Walkthrough.

component-name.generated.ts

The <component-name>.generated.ts file holds the auto-generated editorElement portion of your manifest. The CLI produces this file by reading your React component's JSX, CSS, and prop types.

As you iterate on your component, keeping the manifest in sync depends on how you work:

• Manual edits: The manifest doesn't stay in sync automatically while you edit files yourself. Regenerate it by running wix generate manifest.
• AI edits with the Wix skill: Manifest regeneration happens as part of the Editor React Component Wix skill workflow.

editorElement is the largest part of the manifest. It declares the data your component exposes, the inner elements that Wix users can select, the CSS properties they can customize, and any presets, states, or layout behavior. The editor reads these declarations to build the matching auto panels.

A generated file looks like this:

component-name.tsx

The <component-name>.tsx file is where you write the React code that defines your component. You can write code in other files and include it here, but you must return your main component in this file. This is where the CLI will look for the component definition.

The CLI reads this file when regenerating <component-name>.generated.ts, so the structure of your JSX, CSS classes, and prop types directly shape the auto-generated editorElement. After you edit this file manually, run wix generate manifest to keep the generated manifest in sync.

This file is required for the component to work, so don't delete it. If you add the files on your own, you must include <component-name>.tsx.

When the <component-name>.tsx file is generated, it looks like this:

The file defines a React functional component that imports its props type from <component-name>.props.ts. The props map directly to the data keys in the manifest's editorElement, which is auto-generated from this file, plus id and className, which Wix always provides. For more details, see Runtime Props.

How class names shape the manifest

The generated code composes class names in a specific way, and your own components need to follow the same pattern. Look at the root element:

Each entry does a different job:

• 'my-component': A plain string class, sometimes called a global class. This is the class the manifest's selector matches. It's written as a literal rather than through styles, so it survives CSS Modules scoping and appears in the rendered DOM.
• styles.myComponent: Your own styles from the CSS Module.
• className: The styling that Wix users configure in the editor's panels.

The inner elements follow the same pattern, pairing a global class with a module class: classNames('image', styles.image), classNames('title', styles.title), and so on.

This is what the manifest generator reads. It pairs each global class string in your JSX with the matching rules in <component-name>.module.css, and writes an entry into the generated editorElement. In this component, 'my-component' becomes the root selector, and 'image', 'title', and 'description' each become an inner element with the CSS properties its rules imply. An element with only a module class, like the styles.body wrapper, doesn't become a manifest element. Use a module class alone for purely structural or decorative elements you don't want Wix users to select.

This is a standard React functional component, so you can use all React features including:

• React hooks like useState, useEffect, useCallback.
• Additional props as needed for your functionality.
• Child components and composition.
• External libraries and SDKs.

component-name.props.ts

The <component-name>.props.ts file holds 2 things: your component's props type, and a defaultProps constant with the fallback values for those props.

defaultProps is the single source of truth for the default values of your component's props. It's consumed in 2 places:

• component.tsx: Applies it to the rendered component.

• <component-name>.extension.ts: Passes it to withEditorElementDefaults so the editor panels show the same values.

• Do: Set the default once in defaultProps.

• Don't: Hand-write defaultValue into the manifest's data items.

Note that id and className are excluded from defaultProps with Omit. Wix always provides those, so they never need a fallback.

component.tsx

The component.tsx file is the entry point for your component. It imports your component from <component-name>.tsx and its defaultProps from <component-name>.props.ts, then wires them together with withDefaults.

component.preview.tsx

The component.preview.tsx file is the entry point the editor loads, referenced by resources.editor.componentUrl. By default it renders your component unchanged:

Edit this file when the component should behave or render differently inside the editor than it does on the live site. Common reasons are supplying mock data so the component looks populated on the stage, showing a specific visual state, or disabling an interaction that would get in the way of editing.

Most components never need to change it.

component-name.module.css

The <component-name>.module.css file contains the default styles for the generated component. It uses CSS Modules, which scope class names locally to avoid conflicts with other components on the page.

Because CSS Modules scope your class names, the class you write here isn't necessarily the class that appears in the rendered DOM. Your manifest's selector has to match what actually renders, so add a plain string class to the elements the manifest targets, alongside your CSS Modules class. For more information, see Make your component selectable.

See also

• wix generate manifest
• Manifest Validation and Unsupported Features
• Add an Editor React Component Extension with the Wix CLI
• About Site Extensions
• About the Manifest
• Installation
• Resources
• Tutorial | Build a Manifest Step by Step
• Runtime Props
• About Wix Skills for the CLI