# Render components
> Draw the components editors place on pages with your own React components: the registry, the props each component gets, nested blocks and slots, images, rich text, links, shared sections, client components and the click-to-select preview.
Source: https://docs.bifrostorbit.com/cms/developers/render-blocks/
Editors build pages from components, such as a hero, a card grid or an FAQ list. Your website draws each one with a React component of your own. This page covers everything about that. It assumes the client and types from [Connect a website](https://docs.bifrostorbit.com/cms/developers/connect-a-website/).
## How a page is drawn
```tsx
```
`CmsPage` goes through `page.components` in order. For each block it:
1. Looks up `block.type`, such as `hero`, in the registry.
2. Draws the blocks in each of its slots first, so they are ready to place.
3. Renders your component with the props below.
A `sharedSection` block is replaced by the blocks inside it, so your registry never needs an entry for it. Published pages already arrive that way; the live preview sends the section itself, and the SDK unpacks it.
A block whose type is not in the registry renders a dashed box, "No renderer registered for …", in development, and nothing in production, so a new component never breaks the live website.
`CmsPage` renders `fallback` when the page is `null` or has no components: `Coming soon} />`.
To draw a list of blocks that is not a page body, such as the components of a site-wide entry, use `CmsBlocks`:
```tsx
import { CmsBlocks } from '@bifrost-orbit-cms/sdk/react'
```
`renderComponents(blocks, registry)` does the same and returns an array, for when you need to wrap or count the results.
## The props your component gets
| Prop | Type | Holds |
| --- | --- | --- |
| `block` | `CmsBlock<'hero'>` | The block's fields, plus `type`, `id` and `variant`, typed from the generated types. The easiest to use. |
| `fields` | `Record` | The same fields, untyped |
| `id` | `string` | The block's id, unique on the page and stable across edits |
| `variant` | `string` or `null` | A named look for the block, or `null` for the default |
| `slots` | `Record` | The blocks in each slot, already drawn with your registry |
Type your component with `BlockProps<'key'>`:
```tsx
import type { BlockProps } from '@bifrost-orbit-cms/sdk/react'
export function Faq({ block }: BlockProps<'faq'>) {
return (
)
}
```
Use the field when the parent decides how its children look, such as numbering them or passing extra props:
```tsx
export function Steps({ block }: BlockProps<'steps'>) {
return (
{block.items?.map((step, index) => (
{index + 1}
{step.fields.title}
{step.fields.body}
))}
)
}
```
A node's fields are under `fields`, not on the node itself: `step.fields.title`.
To draw a node with the component registered for it, build its props with a small helper:
```tsx
import type { BlockProps, CmsBlock } from '@bifrost-orbit-cms/sdk/react'
import type { CmsBlockTypes, CmsNode } from '@bifrost-orbit-cms/sdk'
export function nested(node: CmsNode, type: K): BlockProps {
return {
id: node.id,
variant: node.variant,
fields: node.fields as Record,
slots: {},
block: { ...node.fields, type, id: node.id, variant: node.variant } as CmsBlock,
}
}
// in a component
{block.button ? : null}
```
To draw a mixed list with the whole registry, `renderComponents(block.items ?? [], registry)` works too. Importing the registry into a block component that the registry imports is fine, because it is only read while rendering.
Slots can be nested as deep as the schema allows. Each level arrives the same way, with images and links filled in.
## Variants
`variant` names a different look of the same component, such as `dark` or `compact`. It is `null` for the default look. Handle `null` and any value you do not recognise as the default, so content made before a variant existed still renders:
```tsx
const look = { dark: 'bg-black text-white', compact: 'py-4' }[block.variant ?? ''] ?? 'py-12'
```
For choices editors make in the editor, such as a background colour, a Select field on the component is usually clearer, and it is typed.
## Shared sections
A shared section is a group of blocks editors reuse on many pages, such as a newsletter sign-up. Published pages arrive with its blocks in place of the section, so your components draw them like any other blocks. `CmsPage`, `CmsBlocks` and `renderComponents` also unpack a `sharedSection` block if one arrives, as in the live preview. Publishing a shared section refreshes every page, because any page may show it.
## Click to select in the preview
Put `data-cms-id={block.id}` on the outermost element of every component. In the preview, the bridge selects the nearest element with it when an editor clicks, and outlines it when they hover.
- **Nested blocks** you draw yourself need it too: `data-cms-id={step.id}`. Otherwise clicking a step selects the whole list.
- **Components that render nothing**, or a fragment, cannot be selected; clicking selects their parent.
- **Several elements:** put it on a wrapper.
- **Visitors** never load the bridge, so the attribute does nothing for them.
## Components that need the browser
Your components are React Server Components by default: they run on the server and send only HTML. A component that needs state, effects or event handlers, such as an accordion or a carousel, needs `'use client'`:
```tsx
// components/blocks/faq.tsx
'use client'
import { useState } from 'react'
import type { BlockProps } from '@bifrost-orbit-cms/sdk/react'
export function Faq({ block }: BlockProps<'faq'>) {
const [open, setOpen] = useState(null)
return (
{block.items?.map((item) => (
setOpen(item.id)}>
{item.fields.question}
{item.fields.answer}
))}
)
}
```
- A server component may render client components, and pass them the block, which is plain data. The registry can mix both.
- `slots` contains React elements, which can be passed to a client component as `children`.
- With live preview, every block component is also loaded in the browser while previewing, because `CmsLivePage` draws the page there. Keep block components free of server-only code, such as reading files or secret settings. Fetch extra data in the page route instead and pass it down, or in a separate server component the block renders.
## Components that need more data
A block sometimes needs data the page does not carry, such as the latest blog posts for a "Latest news" block. A server component can fetch it:
```tsx
// components/blocks/latest-posts.tsx
import type { BlockProps } from '@bifrost-orbit-cms/sdk/react'
import { cms } from '@/lib/cms'
export async function LatestPosts({ block }: BlockProps<'latestPosts'>) {
const posts = await cms.list({ type: 'blogPost', sort: '-publishedAt', perPage: block.count ?? 3 })
return (
)
}
```
The answer is cached with the `cms:list` tag, which every publish refreshes. Async components cannot be drawn in the browser, so with live preview, render these from a server component around `LivePage`, or give `LivePage` the data as props.
## Template fields outside components
A page also has its own `fields`, defined by its content type, such as a blog post's author and date. Draw them in the page route, around the components:
```tsx
if (result.page.contentType === 'blogPost') {
const fields = result.page.fields as BlogPostFields
return (
{result.page.name}
)
}
```
`BlogPostFields` comes from `cms/types.ts`. In live preview, `useLivePage(page)` gives the page with the editor's latest fields as well as components, so a client template can show both changing as they type.