Template blocks overview

102 pre-built fulldev/ui block variants auto-discovered by the block registry, with Storybook stories and Sanity CMS wiring in progress.

Template blocks are fulldev/ui .astro components installed directly into astro-app/src/components/blocks/ via the shadcn CLI. They share the same flat-props dispatch pattern as custom blocks, so the BlockRenderer treats them identically — no separate registration path.

What fulldev/ui template blocks are

fulldev/ui is a library of pre-built Astro section components distributed through the shadcn registry. Each component is a self-contained .astro file that accepts a typed Props interface. You own the source — once installed, the file lives in your repo and you can modify it freely.

The project ships with 102 variants across 12 categories. Each variant has a companion Storybook story with demo data so you can preview it in isolation without a running Sanity instance.

Sanity schema + GROQ projection wiring for template blocks is tracked in Stories 2.4–2.8. Until a block is wired, it renders via its Storybook story args or static slot content rather than live CMS data.

Installing a block

Each variant is installed individually with the shadcn CLI:

npx shadcn@latest add @fulldev/hero-1

This writes the component file to astro-app/src/components/blocks/hero-1.astro and installs any required ui primitives into astro-app/src/components/ui/. The block is immediately picked up by block-registry.ts — no manual registration needed.

Auto-discovery via the block registry

block-registry.ts uses Vite’s import.meta.glob to scan both blocks/custom/ and blocks/*.astro at build time. Every .astro filename maps to a _type key in the unified allBlocks map:

hero-1.astro  →  allBlocks["hero-1"]
features-3.astro  →  allBlocks["features-3"]

When BlockRenderer receives a Sanity block with _type: "hero-1", it resolves the component from the map and spreads all remaining props directly onto it:

---
// BlockRenderer.astro (simplified)
const Component = allBlocks[block._type]
---
<Component {...block} />

This means adding a new fulldev/ui block to the project requires zero changes to the renderer or registry — drop the file, it works.

Storybook stories

Every template block has a companion story at blocks/{name}.stories.ts. Stories use the Storybook Autodocs tag and export a Default story with realistic demo args. Run Storybook to browse all variants:

npm run storybook

Storybook is deployed to GitHub Pages automatically on pushes to main that touch component files.

CMS wiring status

Wiring a template block to Sanity requires four files and no changes to the .astro component itself:

1. A Sanity schema file in studio/src/schemaTypes/blocks/
2. Registration in studio/src/schemaTypes/index.ts and the page schema
3. A GROQ projection in astro-app/src/lib/sanity.ts
4. A TypeScript type generated by npm run typegen

See the fulldev/ui to Sanity Conversion Guide for the complete 7-step process.

Do not modify files in src/components/ui/ — those are shared primitives used by many blocks. Changes there can break multiple components simultaneously.

Category reference

Category	Variants	Sanity _type names	Description
Heroes	14	hero-1 – hero-14	Headline + CTA + image layouts
Features	6	features-1 – features-6	Icon/card grid layouts
Content	6	content-1 – content-6	Text + image section layouts
CTA	8	cta-1 – cta-8	Call-to-action banners
Pricing	3	pricings-1 – pricings-3	Tier comparison cards
Reviews	5	reviews-1 – reviews-5	Testimonial layouts
Services	7	services-1 – services-7	Service card grids
Articles	6	article-1, article-2, articles-1 – articles-4	Article/blog listing layouts
Media	9	logos-1–3, images-1–2, video-1–3, videos-1–4	Logo clouds, image grids, video sections
Navigation	6	header-1–3, footer-1–3	Site header and footer layouts
FAQ / Steps	7	faqs-1–4, steps-1–3	Accordion FAQ and numbered step sections
Misc	25+	banner-*, stats-*, contact-*, links-*, table-1, etc.	Banners, stats rows, contact forms, link lists, tables

When choosing a variant for a new page section, open Storybook first to compare layouts visually before wiring CMS data.