SitecoreAI documentation for developers

Bring your own components

Content authors and designers use the Components builder to create, align, design, and style components within the SitecoreAI user interface. Developers can enrich this offering by adding their own React or web components, making them available for rendering and usage throughout your SitecoreAI website, in a simple bring-your-own-code (BYOC) workflow. After you create your React code or web component, you bring it into SitecoreAI by registering or scaffolding it.

BYOC has several advantages:

BYOC components appear in the interface like native components, although Sitecore can't access the source or definition, keeping the component code private. You can apply theming in the Components builder, and add them to pages with the drag-and-drop Pages interface, just like any other component.
Hot reloading code in the browser when you develop locally, so that you can immediately see your changes on the page, including rendering the component in Pages or the final website.
Flexibility to create components using your own tools, dependencies, and techniques.
It allows you to reuse components across SitecoreAI sites.
The configuration user interface is generated automatically, based on the JSON schema you pass, allowing content authors to configure the component within the Pages WYSIWYG editor.

Adding BYOC components to SitecoreAI

You add your BYOC components to SitecoreAI in one of two ways:

Registering manually - the components are in a separate byoc folder in your JSS Next.js application.
Scaffolding - the components are part of the components folder in your JSS Next.js application, alongside SXA components.

Rendering modes

BYOC supports a range of development and configuration options to suit your needs.

Client-side - You can choose to render your registered component on the client side, for example: to add a smart input field, display dynamic content, or any other interactive functionality. You add the client components to the byoc/index.client.ts file in your JSS app. You can follow this example.
Hybrid - This is the recommended approach whenever possible. With this approach, a client-side component is prerendered on the server, to improve the initial rendering time and the search engine optimization of the page. A hybrid approach supports server-side indexing of the component and allows you to load static designs even before the app is fully initialized. If you use a hybrid component, make sure you import it inside index.hybrid.ts as shown in this example.

Use SXA Forms alongside BYOC Forms

You can wrap and use Form components created in Forms alongside Bring Your Own Component (BYOC) components.

When an SXA Form component is present in the front-end code, SXA Forms are used as the default form implementation. Existing BYOC Forms on the canvas continue to render, but new BYOC Forms cannot be added to the canvas.

There is no automatic migration path from BYOC Forms to SXA Forms. If you want to use SXA Forms instead of existing BYOC Forms, you must recreate or migrate the forms manually.

SXA Form component support in Content SDK

Content SDK ships a built-in Form component (React) / ScFormComponent (Angular) that renders a form created with SitecoreAI Forms (formerly SXA Forms) inside a Content SDK app. It is registered automatically under the rendering name Form when the app's component map is generated — authors don't need to register or import anything to use it; they just add the Form rendering to a page and set its FormId parameter in Page Builder.

The component itself does not render form fields. It fetches pre-rendered form HTML from Sitecore Edge at runtime and mounts it into the page, client-side only.

Where it lives in the codebase

Concern	Package	File
React component	`@sitecore-content-sdk/react` (re-exported via `@sitecore-content-sdk/nextjs`)	`packages/react/src/components/Form.tsx`
Angular component	`@sitecore-content-sdk/angular`	`packages/angular/src/components/sc-form.component.ts`
Shared loading/runtime logic	`@sitecore-content-sdk/content`	`packages/content/src/form/form.ts`

Rendering parameters (`FormProps.params`)

Parameter	Required	Description
`FormId`	Yes	The ID (GUID) of the Sitecore Form to render. Set by the author when placing the `Form` rendering on a page.
`styles`	No	CSS class(es) applied to the wrapping `<div>`.
`RenderingIdentifier`	No	Used as the wrapping element's `id` attribute.

How it works (runtime flow)

Registration — When a Content SDK app generates its component map (npm run bootstrap / the component-map codegen step), Form is added automatically as a built-in entry pointing at the SDK's Form component (Next.js App Router marks it componentType: 'client' since it must run in the browser). Angular registers ScFormComponent the same way. No entry needs to be added manually unless the app overrides the built-in map.
Client-side only — The component is a client component. It does nothing during SSR; the actual form markup is fetched after hydration, in the browser.
Fetch form markup — On mount, it calls loadForm(contextId, formId, edgeUrl, language), which performs GET {edgeUrl}/v1/forms/publisher/{formId}?sitecoreContextId={contextId} (with &language={language} appended when a page language is available) against the Sitecore Edge Platform.
Page language — The page's current locale is passed to loadForm so the Forms publisher returns the matching multilingual form version, and is also set as the lang attribute on the rendered wrapper element.
Submit/view analytics — Unless the page is in editing mode or the visitor is detected as a bot (isBotClientSide()), subscribeToFormSubmitEvent() attaches a form:engage event listener to the wrapper element. The Forms runtime script (loaded/executed in step 5) dispatches form:engage custom events ({ formId, name: 'VIEWED' | 'SUBMITTED' }) as visitors interact with the form; the listener forwards these to the Content SDK events package's form() function, which sends a FORM custom event (interactionType: VIEWED | SUBMITTED, formId, componentInstanceId) to Sitecore analytics via the configured analytics adapter. componentInstanceId is the rendering's uid with dashes stripped.
- Angular additionally wires an AbortController/AbortSignal into the listener so it's removed automatically when the component is destroyed.

Editing / Page Builder behavior

While the page is in editing mode (context.page.mode.isEditing), the component still loads and renders the form, but suppresses analytics (no form:engage subscription) so interacting with the form in the editor doesn't pollute submitted/viewed analytics.
If the form fails to load while editing, the React component renders an inline ErrorComponent ("There was a problem loading this section") instead of a blank rendering, and logs additional detail to help authors/developers diagnose a bad FormId or Edge connectivity issue.

REST APIs

If you want to use REST APIs to integrate Sitecore Component functionality with your solution, you can follow the Swagger documentation.

If you have suggestions for improving this article, let us know!