---
title: "Bring your own components"
slug: "bring-your-own-components"
abstract: "Register or scaffold your own Web or React components using a bring-your-own-code BYOC flow, which supports both client-side and hybrid rendering."
---
# Bring your own components

Content authors and designers use the [Components builder](https://doc.sitecore.com/sai/en/users/sitecoreai/en/prototyping-components.html) to create, align, design, and style components within the [SitecoreAI](https://doc.sitecore.com/sai/en/users/sitecoreai/en/sitecoreai.html) 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](https://doc.sitecore.com/sai/en/developers/sitecoreai/bring-your-own-components/walkthrough--registering-an-external-react-component/the-registercomponent-method.html "The registerComponent method"), 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](https://doc.sitecore.com/sai/en/developers/sitecoreai/bring-your-own-components/walkthrough--registering-an-external-react-component/walkthrough--registering-an-external-react-component.html "Walkthrough: Registering an external React component") - the components are in a separate `byoc` folder in your JSS Next.js application.
- [Scaffolding](https://doc.sitecore.com/xmc/en/developers/jss/22/jss-xmc/en/scaffold-and-auto-register-your-own-components-in-a-next-js-app.html) - 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)

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.