DEV Community: Zach Scroggins

How I Built This Blog

Zach Scroggins — Thu, 05 Nov 2026 16:10:00 +0000

My first blog post, back in 2021, was a demo. It dropped a React component into the middle of some Markdown to prove that MDX worked. It did work, and then I wrote almost nothing else. The setup was fun to build and tedious to write in.

This is the rebuild. The goal is the same: writing a post should take less effort than putting it off. Nearly everything underneath has changed, and so has the way I built it.

The stack

Next.js 16 with the App Router, Cache Components and the React Compiler
React 19 and TypeScript , with types generated from the content schema
Sanity for content, edited in a Studio that lives in its own repo
Tailwind CSS 4 and shadcn/ui , with shadcn's Typeset styles for post bodies
sugar-high for syntax highlighting, rendered on the server
Vercel for hosting, preview deployments and production

Content lives outside the code

The old blog stored MDX strings in Sanity and compiled them on the server with mdx-bundler. It worked, but the content was really code. A typo in a JSX tag broke the page, and the CMS had no way to warn me first.

Posts are now Portable Text, Sanity's JSON format for rich text. A paragraph is data. A code block is data with a language and a filename. An image is data with required alt text. The site decides how each piece renders, and the Studio checks each piece before I can publish it. I wrote up the Sanity side in Using Sanity to Manage Blog Content.

The site and the Studio are two repos in one folder. The Studio generates TypeScript types straight into the site repo, so a schema change shows up as a type error in the code that reads it.

The Studio deploys itself, too. Merging a pull request into the Studio repo runs a GitHub Actions workflow that installs the dependencies and runs the repo's own sanity deploy, so the hosted Studio always matches main:

on:
  push:
    branches: [main]
    paths-ignore: [' **.md', 'functions/**', 'sanity.blueprint.ts']
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npx sanity deploy --yes
        env:
          SANITY_AUTH_TOKEN: ${{ secrets.SANITY_AUTH_TOKEN }}

Cache Components: static by default, dynamic on purpose

Next.js 16 changes the default. With cacheComponents on, data is only cached where I say so with 'use cache', and anything that reads the request (cookies, headers, search params) has to sit inside a Suspense boundary. That is stricter, and that's the point: every page is a static shell plus the parts I chose to leave dynamic.

import type { NextConfig } from 'next';
import { sanity } from 'next-sanity/live/cache-life';

const nextConfig: NextConfig = {
  cacheComponents: true,
  cacheLife: { default: sanity },
  partialPrefetching: true,
  reactCompiler: true,
  experimental: {
    turbopackRustReactCompiler: true,
  },
};

export default nextConfig;

Blog posts and tag pages are prerendered at build time from generateStaticParams. Every Sanity fetch is tagged, so a publish can invalidate only the pages that used that document instead of rebuilding the site.

The React Compiler handles memoization, so none of my own components need useMemo or useCallback.

Two lessons from the strict model

With partialPrefetching on, /blog/[slug] failed to prerender with an error about reading URL data outside of Suspense. The fix was a loading.tsx next to the page, which gives the route a boundary to stream into, and awaiting params in the page itself.

The same rule applies to client hooks. The Blog link in the header is underlined on any blog page, which means reading the pathname with usePathname. For a slug that wasn't known at build time, that hook suspends during prerendering, so the link wraps itself in Suspense and uses the plain link as the fallback:

export function NavLink({ activeClassName, ...props }: NavLinkProps) {
  return (
    <Suspense fallback={<Link {...props} />}>
      <ActiveNavLink activeClassName={activeClassName} {...props} />
    </Suspense>
  );
}

function ActiveNavLink({ href, className, activeClassName, ...props }: NavLinkProps) {
  const pathname = usePathname();
  const isCurrent = pathname === href;
  const isActive = isCurrent || pathname.startsWith(`${href}/`);

  return (
    <Link
      href={href}
      aria-current={isCurrent ? 'page' : isActive ? 'true' : undefined}
      className={cn(className, isActive && activeClassName)}
      {...props}
    />
  );
}

Styling: Tailwind 4, shadcn/ui and Typeset

The site uses shadcn/ui components and theme tokens throughout, so light and dark mode come from the same set of CSS variables. For post bodies I chose shadcn's Typeset over @tailwindcss/typography. Typeset is one CSS file that lives in my repo, and a few custom properties tune it:

.typeset-blog {
  --typeset-size: 1.0625rem;
  --typeset-leading: 1.8;
  --typeset-flow: 1.25em;
  color: var(--color-muted-foreground);
}

Code blocks are highlighted on the server with sugar-high, using colors from the same theme. That has its own post: Syntax Highlighting with sugar-high.

SEO without a plugin

Next.js covers all of this with file conventions:

app/sitemap.ts lists every post and tag from Sanity.
A route handler serves an RSS feed at /blog/rss.xml.
Each post and tag gets an Open Graph image from next/og, with my logo, the post type and the title.
generateMetadata builds titles, descriptions and canonical URLs from the same queries the pages use.

Every metadata query runs with stega: false. Visual Editing hides invisible characters in strings so the Studio can map text back to fields, and those characters don't belong in a page title or a search result.

Built with an AI pair programmer

I built this with Claude Code, and the way we worked mattered as much as the stack.

Plan before code. We went back and forth on the content model, the tag pages and the preview setup before writing anything. Most of my input went into decisions, not syntax.
Give the agent current docs. Next.js 16 ships its docs inside node_modules, and the repo's AGENTS.md tells agents to read them before writing code, because a model's training data trails the framework. Sanity's Agent Toolkit adds skills for schema design and for wiring Sanity Live into Cache Components, and Sanity's MCP server lets the agent query and edit content directly.
An AGENTS.md in every folder. The parent folder, the site and the Studio each explain what they are and how they connect, so any agent picks up the context, not just Claude.
Check it in a real browser. A passing build isn't the bar. Every change gets checked in the running app: light and dark mode, desktop and phone widths, hover states included.
Keep notes outside the chat. The plan, decisions and a work log live in my Obsidian vault, so the next session starts where the last one stopped.

Everything lands on a feature branch, Vercel builds a preview, and I review the pull request before it merges.

Publishing without a rebuild

When I publish in the Studio, a Sanity Function receives the sync tags for the content that changed and sends them to a route on this site. The route checks a shared secret and expires just those cache entries. Once the function reports back, any open page refreshes itself. A typo fix is live on the site a few seconds after I click Publish, with no build and no deploy.

What's next

The real goal now is simply writing more posts.

Using Sanity to Manage Blog Content

Zach Scroggins — Thu, 05 Nov 2026 16:05:00 +0000

I first wrote about using Sanity for this blog in 2021. My goals then were simple: writing should be enjoyable, content should live apart from the code so a typo fix doesn't need a deploy, and everything should be typed. Those goals still hold. Almost everything about how I meet them has changed.

Portable Text instead of MDX

The old setup stored MDX in a Sanity Markdown field and compiled it on the server. Dropping a React component into the middle of a post felt like magic. It also meant my content was code. A missing closing tag broke the page, and nothing in the CMS could catch it before I published.

This time the post body is Portable Text: an array of typed blocks stored as JSON. A code block in the Studio is saved as plain data:

{
  "_type": "code",
  "language": "typescript",
  "filename": "sanity/live.ts",
  "code": "export const { SanityLive, sanityFetch } = defineLive({ client, strict: true });"
}

The site maps each block type to a React component. Here's what I gained and gave up:

No inline JSX. For a callout, I add a callout type to the schema and a component that renders it. That's a bit more work once, and none after that.
Validation before publishing. Images need alt text. Portfolio articles need their accomplishment line. The Studio won't publish a document that breaks a rule.
One source, many outputs. The same body renders on the page, in the RSS feed and anywhere else, without parsing or executing anything.

One content model for the blog and the portfolio

There are four document types: post, tag, company and role. A post has a kind field, either a normal post or a portfolio article. A portfolio article also has the one-sentence accomplishment shown on my home page, and the field only appears when it's needed:

defineField({
  name: 'accomplishment',
  type: 'text',
  rows: 3,
  group: 'portfolio',
  description: 'The line shown under the role on the home page. It links to this article.',
  hidden: ({document}) => !isPortfolioArticle(document),
  validation: (rule) =>
    rule.custom((value, {document}) =>
      isPortfolioArticle(document) && !value
        ? 'Portfolio articles need an accomplishment'
        : true,
    ),
}),

A company holds an ordered list of roles, and each role holds an ordered list of portfolio articles. The Portfolio section of the home page is one GROQ query that follows those references, and each accomplishment links to its full article. Reordering my work history happens with drag and drop in the Studio, not in a pull request.

Tags are documents too, each with a description, links to the project's homepage, repo and docs, and an icon. Every tag gets its own page listing the posts that use it.

Typed queries with TypeGen

Queries are wrapped in defineQuery, and Sanity TypeGen reads both the schema and the queries to generate a type for each query's result. The Studio repo generates the types straight into the site repo:

typegen: {
  path: '../my-website/{app,components,lib,sanity}/**/*.{ts,tsx}',
  schema: 'schema.json',
  generates: '../my-website/sanity/types.ts',
},

After a schema change I run one script, and any component that reads a renamed or removed field fails to type-check:

npm run typegen

Fetching content with Cache Components

The site runs Next.js 16 with Cache Components, and next-sanity's defineLive connects the two. Strict mode makes every fetch state its perspective (published or drafts) and whether to add stega, the hidden markers that power Visual Editing. That way nothing quietly falls back to the wrong one.

export const { SanityLive, sanityFetch } = defineLive({
  client,
  serverToken: token,
  browserToken: token,
  strict: true,
});

// The app's one shared 'use cache' boundary.
export const cachedSanity: StrictDefinedFetchType = async (options) => {
  'use cache';
  return sanityFetch(options);
};

Pages check for draft mode once, then pass perspective and stega down to the components that fetch. Visitors get published content from the static shell. I get drafts with click-to-edit markers, from the same components.

Live preview with the Presentation Tool

The 2021 post called Sanity's preview the best of any headless CMS because changes showed up as I typed. That's still true, and the Presentation Tool goes further. The Studio shows the real site beside the editor, and clicking any text on the page jumps to the field it came from.

Setting it up takes a few lines in the Studio config:

presentationTool({
  resolve,
  previewUrl: {
    initial: process.env.SANITY_STUDIO_PREVIEW_URL || 'http://localhost:3000',
    previewMode: {enable: '/api/draft-mode/enable', disable: '/api/draft-mode/disable'},
  },
}),

On the site, it takes one route handler that checks the Studio's preview secret and turns on draft mode:

import { client } from '@/sanity/client';
import { defineEnableDraftMode } from 'next-sanity/draft-mode';

export const { GET } = defineEnableDraftMode({
  client: client.withConfig({ token: process.env.SANITY_API_READ_TOKEN }),
});

The resolve option maps routes to documents both ways. Opening /blog/some-post in the preview selects that post. Opening a post in the editor lists every page it appears on, including the home page for portfolio articles.

Sanity and AI agents

Sanity has leaned into AI tooling, and it paid off on this project. The Agent Toolkit gives coding agents skills for schema design, GROQ and framework integrations, and the MCP server lets them query and change content directly. While I built this site with Claude Code, it read the dataset to check its own work and seeded the tags and the first drafts of my portfolio articles with scripts. I then review and edit everything in the Studio.

If you're starting today

Model the content, not the page. Tags, companies and roles as documents made both the blog and the portfolio easy to build.
Turn on strict in defineLive. Being explicit about perspective prevents a whole class of preview bugs.
Keep stega out of metadata, sitemaps and feeds with stega: false, and run stegaClean() on any Sanity string before comparing it.
Generate types, and regenerate them every time the schema changes.

Next, I'll walk through how this blog's code blocks work in Syntax Highlighting with sugar-high.

Syntax Highlighting with sugar-high

Zach Scroggins — Thu, 05 Nov 2026 16:00:00 +0000

The first version of this post was a gallery of code blocks. It showed off rehype-prism-plus, code titles, line highlighting, and a workaround for esbuild on Windows. Every one of those plugins is gone now. Code blocks are simpler, faster and match the site's theme in light and dark mode.

How a code block gets onto the page

I write the code in Sanity Studio with the code input plugin, picking a language and adding an optional filename.
Sanity stores the block as plain data: code, language, filename and any highlightedLines.
A Portable Text component on the site passes the code to sugar-high during server rendering.
sugar-high returns HTML with one class per token, and CSS variables color them.

No highlighter ships to the browser. The page arrives already colored.

The Studio side

The post body allows a code block next to text and images. Limiting the language list keeps the Studio dropdown short and matches what the site can highlight:

defineArrayMember({
  type: 'code',
  options: {
    withFilename: true,
    languageAlternatives: [
      {title: 'TypeScript', value: 'typescript'},
      {title: 'TSX', value: 'tsx'},
      {title: 'Shell', value: 'sh'},
      {title: 'Python', value: 'python'},
      // JSON, CSS, HTML, SQL, YAML, Markdown...
    ],
  },
}),

The renderer

Here's a trimmed version of the component. The Studio stores language names like sh and tsx, and sugar-high's lang() helper turns them into its own names (shell, typescript). stegaClean removes the hidden characters Visual Editing adds to strings in preview, which would otherwise end up inside the code. The highlighted lines handle line highlighting, covered below.

export function CodeBlock({ value }: { value: CodeValue }) {
  if (!value.code) return null;
  const code = stegaClean(value.code);
  const language = stegaClean(value.language);
  const highlighted = new Set(value.highlightedLines ?? []);
  const html = highlight(code, {
    lang: language ? lang(language) : undefined,
    // sugar-high counts lines from 0; the Studio counts from 1.
    markLine(line) {
      if (highlighted.has(line.index + 1)) line.className += ' sh__line--highlighted';
    },
  });

  return (
    <figure data-slot="code-block">
      <figcaption>
        {value.filename}
        <CopyButton code={code} />
      </figcaption>
      <pre data-language={language}>
        <code dangerouslySetInnerHTML={{ __html: html }} />
      </pre>
    </figure>
  );
}

The theme

sugar-high reads every color from a CSS custom property. I picked values that match the site's green and blue accents, then defined them again under .dark. Switching themes with next-themes recolors every code block, with no second stylesheet and no JavaScript.

:root {
  --sh-class: oklch(52% 0.18 259.8);
  --sh-property: oklch(50% 0.14 211.5);
  --sh-string: oklch(52% 0.17 151.7);
  --sh-keyword: oklch(52% 0.2 340);
  --sh-comment: oklch(55.1% 0.027 264.364);
}
.dark {
  --sh-class: oklch(70% 0.15 259.8);
  --sh-property: oklch(78.9% 0.154 211.53);
  --sh-string: oklch(79.2% 0.209 151.711);
  --sh-keyword: oklch(75% 0.17 340);
  --sh-comment: oklch(55.1% 0.027 264.364);
}

Why sugar-high and not Shiki

Shiki uses the same TextMate grammars as VS Code, so it's the most accurate option, especially for unusual syntax. It also loads a grammar and a theme for every language you use. sugar-high is a small tokenizer with no dependencies. It covers JavaScript, TypeScript and JSX well, supports about thirty other languages, and runs anywhere JavaScript does, including a Server Component. Nearly everything I write about is TypeScript, so that's the right trade for this blog. If I start posting a lot of Rust or Go, I'll look at this again.

Examples

Shell

npm create sanity@latest -- --template clean --typescript --output-path my-website-cms
npm install next-sanity @sanity/image-url sugar-high

TypeScript

A GROQ query from this site. defineQuery lets TypeGen generate the type of the result.

export const COMPANY_JOBS_QUERY = defineQuery(`
  *[_type == "company" && slug.current == $company][0]{
    _id,
    name,
    roles[]->{
      _id,
      title,
      accomplishments[]->{
        _id,
        accomplishment,
        "slug": slug.current,
        tags[]->{_id, name, "slug": slug.current}
      }
    }
  }
`);

TSX

An example server component in the same style as this site's: it fetches through the shared cache boundary and renders a list.

export async function LatestPosts({ perspective, stega }: DynamicFetchOptions) {
  const { data: posts } = await cachedSanity({ query: POSTS_QUERY, perspective, stega });

  return (
    <ul className="space-y-4">
      {posts.slice(0, 3).map((post) => (
        <li key={post._id}>
          <Link href={`/blog/${post.slug}`} className="font-semibold hover:underline">
            {post.title}
          </Link>
        </li>
      ))}
    </ul>
  );
}

Python

The 2021 version of this post had a long Pig Latin script. Here it is again, rewritten with type hints and a regular expression that leaves punctuation alone. The two highlighted lines do the real work.

import re

VOWELS = set("aeiouAEIOU")

def to_pig_latin(word: str) -> str:
    """Translate one word: leading consonants move to the end, then add ay."""
    if word[0] in VOWELS:
        return f"{word}yay"
    for i, letter in enumerate(word):
        if letter in VOWELS:
            return f"{word[i:]}{word[:i]}ay"
    return f"{word}ay"

def translate(sentence: str) -> str:
    # Swap each run of letters; spaces and punctuation stay where they are.
    return re.sub(r"[A-Za-z]+", lambda match: to_pig_latin(match.group()), sentence)

if __name__ == " __main__":
    print(translate(input("Sentence: ")))

JSON

The Studio's scripts. typegen extracts the schema and regenerates the site's types in one step.

{
  "scripts": {
    "dev": "sanity dev",
    "build": "sanity build",
    "deploy": "sanity deploy",
    "typegen": "sanity schema extract --enforce-required-fields --force && sanity typegen generate"
  }
}

Highlighting lines

Some examples only need you to look at a line or two. In the Studio, clicking a line number in the code input toggles that line, and Sanity saves the numbers in the block's highlightedLines array. There's no extra field to add to the schema.

On the site, sugar-high's markLine option runs once for every line. The renderer above adds a class to each line in that array (sugar-high counts lines from 0, the Studio from 1), and a few lines of CSS turn the class into a tinted bar with a green edge. The highlighted rules below are the ones doing it:

[data-slot='code-block'] code {
  display: grid;
  width: max-content;
  min-width: 100%;
}
[data-slot='code-block'] .sh__line {
  min-height: 1lh;
  margin-inline: -1.25rem;
  padding-inline: 1.25rem;
}
[data-slot='code-block'] .sh__line--highlighted {
  background-color: color-mix(in oklab, var(--color-green-500) 12%, transparent);
  box-shadow: inset 3px 0 0 var(--color-green-500);
}

Making each line a grid row is what lets the bar run the full width of the block, even when a long line scrolls sideways. The negative margin pulls each line into the block's side padding, and min-height: 1lh keeps empty lines from collapsing. Dark mode uses the same rule with a lighter green.