Editor.json for Custom Lightning Types

An optional file that you can configure for a custom Lightning type that you create. With this file, you can customize how user input is collected by defining the input component.

You can define a single editor for your entire custom Lightning type.

Let’s say that you have a custom Lightning type named flightFilter with a schema.json file. For information about how to create custom lightning types, see LightningTypeBundle Metadata API.

You configure editor.json to define an editor for your entire custom Lightning type. As a result, the same editor applies whenever you use the instance of this type as input.

Here’s an example of what the editor.json file can look like for the custom Lightning type flightFilter.

To illustrate the concept, this example uses the Apex Class.

The Filter class contains two fields: price and discountPercentage.

By default, individual out-of-the-box editors are displayed to collect user input. This example uses c/myFilterComponent in an editor to collect user input that's related to the flight search filter criteria.

For example, you use a slider to select a value for Discount Percentage, and you apply minimum and maximum limits for Price.

Let’s create a custom LWC component, myFilterComponent, that contains the fields price and discountPercentage.

Here’s a sample code that shows the LWC component myFilterComponent.

Reference this component in the editor.json file.

Here’s how to reference the LWC component myFilterComponent to override the editor for the Filter input in the editor.json file.

Let’s say that you built the LWC component myExistingFilterComponent that contains the fields with the names cost and discountPercentage.

You decide to reuse the myExistingFilterComponent instead of creating a new one, myFilterComponent, with field names price and discountPercentage. However, the field name price in the Flight Class doesn’t match the field name cost in myExistingFilterComponent.

To map the fields from Flight class to the corresponding fields in the LWC component myExistingFilterComponent, use attribute mapping.

Here’s a sample code that shows how to reference myExistingFilterComponent to override the editor for the Filter input in the editor.json file with attribute mapping.

The expression “cost”: “{!$attr.price}” indicates:

• cost: Field in the LWC component myExistingFilterComponent
• {!$attr}: Pointer to the Filter class field
• price: Field in the Filter class
• {!$attr.price}: Links the price field of the Filter Apex class to the cost field of the LWC component myExistingFilterComponent and vice versa.