How it works

Your website has a banner that says “Free shipping over $75.” You want it to say “Free shipping over $50.” The component stays the same; only its saved title input changes.

Blocks stores the component's inputs as JSON. Its types define the editing fields, a saved file records the new headline, and your application reads the published inputs to render the banner.

Try the interactive example to see the form, saved configuration, and website together.

From typed code to a published headline

1. Define the behavior in code

Start with an ordinary React component. Its props define the two inputs that content can supply:

interface Props {
  title: string;
  href: string;
}
 
export function PromoBanner({ title, href }: Props) {
  return <a href={href}>{title}</a>;
}

Give the component the name "promo-banner" in your block map, the object of functions configuration is allowed to call: { "promo-banner": PromoBanner }. That name lets the saved JSON refer to the function.

The component receives an ordinary string for title and renders it as a link. Changing the headline does not require changing this function. See The block map for registration.

2. Turn the types into editing fields

In your project, the schema generator reads Props and writes .deco/schema.gen.json, a description of the editable inputs. The Site Editor uses that schema to build fields for title and href.

An editor can change the headline through a text field without editing TypeScript. Forms from types explains how the fields and their labels follow your code.

3. Save the inputs as configuration

A block is a function call written as data. Its __resolveType field selects "promo-banner" from the block map; title and href hold the inputs.

Save the call in your repository. After changing the headline to $50, its configuration looks like this:

{
  "__resolveType": "promo-banner",
  "title": "Free shipping over $50",
  "href": "/summer"
}

SummerBanner is the saved configuration's name; promo-banner identifies the function it calls.

In the proposed Next editor integration, the Site Editor app inside Studio changes these same saved inputs through generated forms. A developer can edit the JSON directly, and an agent can change the same file with its repository tools. All three work on the same configuration. The current Site Editor guides describe released 7.x sites; their runtime protocol is separate from the Next integration contract. See Saved blocks for naming and reuse.

4. Review and publish the change

Commit the JSON change on a working branch, open a pull request, and review the diff before merging it into your production branch, usually main. The diff shows title changing from “Free shipping over $75” to “Free shipping over $50,” while the component and link remain unchanged.

With bundled content, run content generation before the application build, then deploy the configuration with the application. The reviewed headline reaches production with that deployment.

This keeps code and configuration versioned together, so you can inspect the diff and revert a change. Content and loaders explains how the files enter your build; Deployment covers delivery.

The optional hosted publishing service provides another delivery path: prepared content releases can reach running servers through background updates, without a new application build.

5. Resolve and render the published content

Once the updated content is published, your application reads it through a CMS instance configured with the block map and content. That published content version is called a release. For each request, the application gets a release client and asks for the saved banner:

const client = cms.forRelease();
const [banner, error] = await client.resolve("SummerBanner");

The client reads SummerBanner, finds promo-banner in the block map, and calls PromoBanner with the saved title and href. The component returns JSX for your React framework to render. Visitors see “Free shipping over $50.”

The Quickstart shows the CMS setup and error handling. Rendering explains the integration for your framework.

Where to go next

• Quickstart: connect the pieces in an application.
• Blocks: understand function calls, nested inputs, and resolution.
• Next editor integration: understand the proposed schema and content protocol. For a released 7.x website, use the current Site Editor guides.
• A/B tests: an advanced example of rule-based configuration.
• Releases and drafts: understand published content and work in progress.

Reference