Skip to main content
Avocado Studio ships with 20 ready-to-use block types covering hero sections, content layouts, conversion CTAs, media, and navigation chrome. They are defined in packages/shared/src/blocks/ (schemas + field metadata) and rendered by packages/blocks/src/blocks/ (React components + CSS).
The fastest way to see every built-in block rendered with default props is the live catalogue at avocadostudio.dev/components — sidebar, viewport switcher, and a live prop editor included. The monorepo’s own apps/site also serves it at http://localhost:3000/catalogue in dev. Example sites and scaffolded projects do not ship that route.

​
When to use built-ins vs. your own components

On a site that already exists, your own components are the blocks. The built-ins are a starting catalogue for sites built from scratch — they are not the thing you are expected to rebuild your site out of. See Custom blocks.
  • Bring your own when you have an existing component library or design tokens to preserve — which is the usual case. Register the components you already ship and declare which of their props are content.
  • Use the built-ins when you are scaffolding a new site and want a content model without designing one. They cover the common marketing and landing patterns and are fully wired into the AI planner, asset manager, and preview overlay.
  • Mix them. Built-ins and your own blocks coexist in one manifest. List the built-ins you actually render in blockTypes, or the editor offers all of them — see custom blocks.

​
Catalogue

​
Content

​
Conversion

​
Media

​
Layout

These blocks are structurally pinned — they cannot be added, moved, or removed by the AI. Every page has exactly one of each, and they render as global chrome.

​
Section background

Sixteen built-ins — all but Hero, Banner, SiteHeader and Footer — take a tone prop, shown in the property panel as Background: default is the page ground, panel the step in from it, inverse the full-bleed band. An unknown value falls back to the page ground. Colours come from the theme’s tokens, so a theme restyles all three.

​
Field types you’ll see

Each block declares per-field metadata (kind) that drives editor UI, AI behavior, and inline editability:
reference is deliberately read-only. A CMS reference is a pointer — Storyblok’s { linktype, id, cached_url }, a Contentful entry link, a Sanity reference — not an href. Flattening one to a string breaks renames and makes the publish diff report the field as changed forever, so the panel shows the target and refuses the edit rather than corrupting it.
Four flags change what a field means rather than how it is drawn: inlineEditable: false says a string is not edited in place; panelOnly says nothing on the page draws it, which takes it out of the coverage denominator; readOnly shows a value that can never be changed here; and internal: true marks a prop the storage system owns (a Storyblok _uid, a Contentful sys) so no surface shows it to a person and no planner is told it exists. See Block System Architecture for the full vocabulary and the lifecycle from definition to render, and Coverage checks for how the flags affect the numbers.

​
Extending the set

Register your own blocks

Author blocks in your own repo from components you already have, and expose them through your manifest. This is the normal path.

Declare a CMS-backed model

One field table derives the schema, the panel metadata, the projection out of your CMS and the merge back into it.
If you register a block under a name a built-in already uses — a Hero of your own — yours wins, and the property panel takes your declared field metadata over Avocado’s. That is deliberate, but a name collision is worth knowing about: run panelCoverage, which reports it as colliding_type.