Forem: Eugene Boruhov

Automating your content with Sanity's Agent Actions, Functions & Blueprints

Eugene Boruhov — Mon, 18 Aug 2025 17:38:07 +0000

For a long time, we collectively treated the CMS as a "content store" - a convenient database with a UI where non-developers could edit text and images without, as we’d say, a pain in the ass. Its job was to hold things.

But over the past few years, Sanity has been aggressively pushing the boundaries of that definition. They transitioned from a simple content store into a true Content Operating System. It became a hub for structured data you can model, query, and connect in powerful new ways.

Yet, for all this progress, we as developers still hit a ceiling. When it came to a crucial part of the modern stack, automation, we had to look elsewhere. We found ourselves reaching for Vercel or Netlify functions to handle tasks that felt like they should belong inside Sanity. We needed to enrich content on publish, trigger a validation workflow or sync data with another service.

This approach worked, but it always felt like a workaround. It created a divide, forcing us to manage fragmented architectures and spread authentication tokens across platforms. Our logic lived in one place, and our content in another.

With the Spring Release, that is no longer the case. Sanity has finally delivered the missing piece. The introduction of native AI and serverless capabilities means the platform is no longer just a sophisticated content store - it has become a truly mature Content Engine. The logic and the content can now live together, closing the gap and fundamentally changing what's possible within a single, unified system.

AI & Automation Inside Sanity

So, what powers this new Content Engine? Sanity has delivered a trio of interconnected features that together create a complete and native ecosystem for automation. While still in their early stages, they already form a powerful foundation.

Think of it as a complete toolkit with three core components:

Agent Actions (AI brains). This is the intelligence layer. Agent Actions are schema-aware AI instructions that can programmatically generate, transform, and translate your content. They aren't just simple text prompts - they understand your content models, which allows for incredibly precise and structured results.
Functions (automation engine). This is the serverless power we've been waiting for. Functions are event-driven pieces of code that live right inside your Sanity project and react to content changes. Triggered by content operations like ⁠publish, ⁠create, or ⁠delete, these functions spring into action, running your code and eliminating the need for external webhooks or authentication boilerplate.
Blueprints (infrastructure scaffolding). This is how you manage your new serverless capabilities using an infrastructure-as-code approach. Blueprints allow you to declaratively define, configure, and deploy your Functions, ensuring your automation setup is version-controlled, repeatable, and easy to manage from the command line.

The true power of this toolkit lies in how these components work together. You can use an Agent Action to define an AI task, then invoke it from a Function that triggers when a document is published, all managed and deployed via a Blueprint.

This is the integrated system that ends the workarounds. Let's break it down, starting with the AI brains of the operation: Agent Actions.

Agent Actions

The core of Sanity's new AI capabilities is powered by Agent Actions. Think of them as an intelligent, schema-aware layer that sits on top of your content. They know what a "blog post" is in your project, what fields it has, and how a "product" might reference a "category." This awareness allows them to perform tasks with a level of precision that was previously impossible without complex, hand-written code.

The Agent Actions are broken down into four distinct capabilities:

Generate: This is your creative engine. It goes beyond just text, allowing you to create entire documents from scratch, complete with structured data and even generated images. It's perfect for drafting a blog post from a title, populating a product description, or creating visual assets that match your content's context.
Transform: This is your intelligent editor. Instead of crude find-and-replace operations, Transform can modify existing documents with nuance. Use it to change an article's tone from formal to casual, summarize a long passage into a concise description, or update fields while preserving the integrity of the rest of the document.
Translate: Purpose-built for localization, this action handles both document-level and field-level translation. It's smart enough to protect brand names, technical terms, or other phrases you define, ensuring your core messaging remains consistent across languages.
Prompt: This is your direct line to an LLM, but with your Sanity content as the built-in context. It allows you to ask questions, analyze data, or run custom instructions against your documents without having to pipe the content to an external service.

These powerful actions are already being integrated across the Sanity ecosystem. The recently introduced Sanity MCP, which allows AI coding assistants to interact with Sanity projects, uses this new Agent Actions API under the hood.

For developers, getting started is straightforward. The actions are exposed as a new dedicated scope within the familiar @sanity/client, making them easy to call from anywhere you can run JavaScript. But how do we put them on autopilot? For that, we need an engine.

Functions & Blueprints

An AI brain is powerful, but its true potential is unlocked when it can act on its own. This is where Sanity Functions come in - the serverless engine we've been waiting for. This is the feature that finally allows us to stop outsourcing our automation logic to external platforms.

Functions are event-driven, single-purpose pieces of code that live directly within your Sanity project. They respond to content changes, such as publish, update, or delete - and execute your logic right on Sanity's infrastructure.

Functions CLI

Sanity has built a complete local-first workflow around Functions. The CLI provides a robust development environment:

Use sanity functions dev to run a local emulator for real-time development
Simulate trigger events with ⁠sanity functions test. It lets you invoke your function locally with a mock payload by passing either a local JSON file or the ID of a document in your dataset
When you need to debug a deployed function, you can stream its logs directly to your terminal with sanity functions logs

Automation with GROQ Delta Functions

What makes Sanity Functions particularly powerful is their deep integration with the content layer. Using special GROQ Delta Functions, your code can understand not just the current state of a document, but precisely what changed.

before() and after() give you snapshots of the document before and after the triggering event
delta::changedAny() and delta::changedOnly() let you check if specific fields were modified. Did the title change? Or only the title?
delta::operation() tells you if the document was created, updated, or deleted

You can build workflows that only run when a specific field is changed or when a document is first created, preventing unnecessary executions and complex boilerplate code.

Infrastructure as Code with Blueprints

A powerful engine needs a robust control system. Blueprints provide exactly that. They bring the discipline of infrastructure-as-code to your Sanity project, allowing you to define and manage your Functions (and other future Sanity resources) in a version-controlled file: sanity.blueprint.ts.

The workflow is clean and mirrors best practices from modern DevOps:

Define: you declare your functions and their triggers in the blueprint file
Plan: run ⁠sanity blueprints plan to see what changes will be made to your cloud environment
Deploy: execute ⁠sanity blueprints deploy to push your functions to Sanity's infrastructure
Manage: you can view info with sanity blueprints info or tear down resources with ⁠sanity blueprints destroy

This approach makes your automation setup repeatable, reviewable, and easy to manage as a team. And for a quick start, Sanity has provided a library of Recipes with pre-built patterns for common use cases.

Now we have the full picture: the AI brains with Agent Actions and the automation engine with Functions, all managed via Blueprints. Now, let’s put it all together and build something real.

From Theory to Practice

This is where the new toolkit moves from a list of features to a powerful, integrated system. At FocusReactive, we immediately used these tools to tackle a common content challenge: generating relevant, high-quality FAQ sections for our technical blog posts.

Here’s how we built it, showcasing how you can use Agent Actions both manually with a UI trigger and automatically in a hands-off workflow.

FAQ Schema

First things first, we need a home for our FAQ content. We'll set up a pretty standard schema with types for the FAQ section and its individual items:

// schemas/blog/postFaq.ts
export default {
  name: 'postFaq',
  title: 'Post FAQ',
  type: 'object',
  fields: [
    {
      name: 'title',
      title: 'Title',
      type: 'string',
      validation: (Rule) => Rule.required(),
    },
    {
      name: 'description',
      title: 'Description',
      type: 'array',
      of: [{ type: 'block' }],
    },
    {
      name: 'items',
      title: 'FAQ Items',
      type: 'array',
      of: [{ type: 'postFaqItem' }],
      validation: (Rule) => Rule.required().min(1),
    },
  ],
};

// schemas/blog/postFaqItem.ts
export defaul {
  name: 'postFaqItem',
  title: 'Post FAQ Item',
  type: 'object',
  fields: [
    {
      name: 'title',
      title: 'Title',
      type: 'string',
      validation: (Rule) => Rule.required(),
    },
    {
      name: 'richText',
      title: 'Text',
      type: 'array',
      of: [{ type: 'block' }],
      validation: (Rule) => Rule.required(),
    },
  ],
};

Custom Studio Action

First, we wanted to give editors manual control. What if they want to regenerate an FAQ for an already-published post? This is a perfect use case for calling an Agent Action directly from a custom Document Action in the Studio.

This demonstrates the power of the Agent Action API on its own - no serverless function needed.

We created a custom action that appears in the document's dropdown menu:

// actions/GenerateFaqAction.tsx
import { useState } from 'react';
import {
    DocumentActionComponent,
    DocumentActionDescription,
    DocumentActionProps,
    useClient,
} from 'sanity';
import { RobotIcon } from '@sanity/icons';

export const GenerateFaqAction: DocumentActionComponent = (
    props: DocumentActionProps,
): DocumentActionDescription | null => {
    const [isGenerating, setIsGenerating] = useState(false);
    const agentClient = useClient({ apiVersion: 'vX' });

    if (props.type !== 'post') {
        return null;
    }

    const handleGenerateFaq = async () => {
        setIsGenerating(true);

        try {
            const document = props.draft || props.published;

            if (!document) {
                alert('❌ No document data available');
                return;
            }

            const { _id, title } = document;

            console.log(`🔄 Regenerating FAQ for: ${title}`);

            await agentClient.patch(_id).unset(['faq']).commit();

            console.log(`🗑️ Existing FAQ cleared for: ${title}`);

            const result = await agentClient.agent.action.generate({
                schemaId: '_.schemas.default',
                targetDocument: {
                    operation: 'edit',
                    _id,
                },
                // The instruction below is a simplified example. In a real-world application,
                // you could provide much more detailed requirements, including rules for
                // tone of voice, brand guidelines, or specific formatting for the output
                instruction: `Generate 5-7 relevant FAQ items for this blog post about $blogTitle.
Create questions that readers would commonly ask about this technical topic.
Provide comprehensive, helpful answers based on the blog content ($blogContent) and description ($blogDescription).
Make the questions specific and actionable.
Focus on practical implementation details, common issues, and best practices.`,
                instructionParams: {
                    blogTitle: { type: 'field' as const, path: 'title' },
                    blogContent: { type: 'field' as const, path: 'content' },
                    blogDescription: { type: 'field' as const, path: 'description' },
                },
                target: {
                    path: ['faq'],
                },
            });

            console.log(`✅ FAQ regenerated successfully for: ${title}`);

            props.onComplete();

            alert(`✅ FAQ generated successfully for "${title}"!\\n\\nThe document has been updated.`);
        } catch (error) {
            console.error('❌ Error generating FAQ:', error);
            alert(`❌ Error generating FAQ: ${error.message || 'Unknown error'}`);
        } finally {
            setIsGenerating(false);
        }
    };

    return {
        label: isGenerating ? 'Generating FAQ...' : 'Generate FAQ',
        icon: RobotIcon,
        disabled: isGenerating,
        onHandle: handleGenerateFaq,
        title: 'Generate FAQ section using AI based on the blog content',
    };
};

With this in place, an editor can now click a button in the Studio, and the AI will generate and populate the FAQ field on demand.

Triggering on Publish

Now for the magic. We want to generate the FAQ automatically when a new post is published. This is where Functions and Blueprints come into play.

We first define our workflow in sanity.blueprint.ts. We're telling Sanity to run a function named generate-faq only on the publish event, and only for documents that are posts and don't already have an FAQ.

// sanity.blueprint.ts
import { defineBlueprint, defineDocumentFunction } from '@sanity/blueprints';

export default defineBlueprint({
    resources: [
        defineDocumentFunction({
            name: 'generate-faq',
            event: {
                on: ['publish'],
                filter: '_type == "post" && !defined(faq)',
                projection: '{_id, title}',
            },
        }),
    ],
});

Next, we create the function itself. This code will look very similar to our custom action, but instead of being triggered by a user click, it's triggered by the publish event.

// functions/generate-faq/index.ts 
import { documentEventHandler } from '@sanity/functions';
import { createClient } from '@sanity/client';

export const handler = documentEventHandler(async ({ context, event }) => {
    const client = createClient({
        ...context.clientOptions,
        apiVersion: 'vX', // Required for Agent Actions
        useCdn: false,
    });

    const { _id, title } = event.data;

    console.log(`🚀 FAQ generation triggered for: ${_id} (${title})`);

    if (!_id) {
        console.error('❌ Missing _id in event data');
        return;
    }

    try {
        console.log(`🤖 Generating FAQ using AI for: ${title}`);

        const result = await client.agent.action.generate({
            schemaId: '_.schemas.fr-website',
            targetDocument: {
                operation: 'edit',
                _id: `drafts.${_id}`, // Create/update draft version instead of published
            },
            instruction: `Generate 5-7 relevant FAQ items for this blog post about $blogTitle.
Create questions that readers would commonly ask about this technical topic.
Provide comprehensive, helpful answers based on the blog content ($blogContent) and description ($blogDescription).
Make the questions specific and actionable.
Focus on practical implementation details, common issues, and best practices.`,
            instructionParams: {
                blogTitle: { type: 'field' as const, path: 'title' },
                blogContent: { type: 'field' as const, path: 'content' },
                blogDescription: { type: 'field' as const, path: 'description' },
            },
            target: {
                include: ['faq'],
            },
            noWrite: context.local, // Don't write when testing locally
        });

        console.log(`✅ Successfully generated FAQ for: ${title} (${result._id})`);
    } catch (error) {
        console.error(`❌ Error generating FAQ for ${title}:`, error);
        throw error;
    }
});

Deploy and Go

Finally, we deploy our automation with a single command:

sanity blueprints deploy

And now our workflow is complete. We have an on-demand, manual trigger inside the Studio and a fully automated, hands-off process for new content. This dual approach perfectly illustrates the flexibility of Sanity's new toolkit - you can meet editors where they are, while also building powerful, invisible automations.

Conclusion

The June 2025 update is more than just another set of features, it represents a fundamental shift in what we can expect from a content platform. At FocusReactive, we couldn't be more excited about this evolution.

We are already putting this knowledge into practice and are committed to using these capabilities to empower our clients. Our goal is to equip their content managers with the best possible tools, creating intuitive, AI-assisted workflows that automate repetitive tasks and unlock new creative potential.

A huge thank you to the entire Sanity team for their incredible vision and execution. It feels like every month they deliver something new and exciting that moves the entire industry forward. We can't wait to build with this and see what comes next.

To give you a concrete example of the output, you can see the AI-generated FAQ section for this article right below.

Integrating GraphQL Codegen with Storyblok: Step-by-Step Guide

Eugene Boruhov — Mon, 15 Jan 2024 11:39:33 +0000

Storyblok is a modern headless CMS that offers developers the flexibility to manage content independently of the presentation layer. It supports GraphQL, enabling precise and efficient data retrieval, which is important for achieving high performance in web applications.

The @graphql-codegen library is a bridge between your GraphQL schema and the actual code you write. It automates the generation of boilerplate code, ensuring that your data fetching layer is always up to date with your content structure.

Combing the power of code generation in Storyblok projects, we eliminate the disconnect between frontend applications and the CMS backend. In the following sections, we'll explore how to set up and benefit from this powerful integration, step by step.

In this article, we will detail the process of integrating these powerful tools. The aim is to streamline data fetching from Storyblok, simplifying it into a few straightforward steps:

Write the necessary GraphQL query for the data you require
Run GraphQL Codegen to transform these queries into usable code
Learn how to utilize the generated utilities to retrieve this data efficiently

Additionally, for a comprehensive understanding and hands-on experience, we have made available a repository containing the final result of this integration. You can access and explore this repository at FocusReactive's Demo Storyblok GraphQL Codegen. This resource provides a practical reference, allowing you to see the integration in action and to use it as a starting point for your projects. Also, you can use this demo as a tool for generating types for your existing project, simply add your queries to the src/graphql directory and insert your token into the .env.local file.

Viewing and fetching the Storyblok GraphQL schema
Configuring GraphQL Codegen for Storyblok
Advanced techniques and customizations
Benefits of this integration
Conclusion

Viewing and fetching the Storyblok GraphQL schema

To kickstart the process of integrating GraphQL Codegen with Storyblok, you first need to understand how to access and utilize the GraphQL schema provided by Storyblok. Fortunately, Storyblok offers a straightforward way to view your GraphQL schema. You can access it at https://gapi-browser.storyblok.com/?token=, but don’t forget to replace STORYBLOK_API_TOKEN with your actual token.

Installation

The first step is to set up all necessary tools and save the schema right inside your project. Let’s install the GraphQL Codegen CLI and required dependencies:

npm i graphql
npm i -D typescript @graphql-codegen/cli @graphql-codegen/schema-ast

@graphql-codegen/cli is the heart of the operation, orchestrating the generation of types and operations from your GraphQL schema
@graphql-codegen/schema-ast plugin allows us to download the schema directly in our development environment

Initial codegen configuration

Once the tools are in place, it's time to configure them to work with your Storyblok project. The reason why we want to store schema inside the project is to ensure that your IDE can provide helpful autocompletion and syntax highlighting.

Here's a template for your codegen.ts configuration using the schema-ast plugin to connect to Storyblok and fetch the schema:

import type { CodegenConfig } from '@graphql-codegen/cli';
import { loadEnvConfig } from '@next/env';

// if you're using Next.js
loadEnvConfig(process.cwd());

const config: CodegenConfig = {
  overwrite: true,
  generates: {
    'src/generated/storyblok.graphql': {
      schema: {
        'https://gapi.storyblok.com/v1/api': {
          headers: {
            token: process.env.STORYBLOK_API_TOKEN!, // don't forget to add your token
            version: process.env.NODE_ENV === 'production' ? 'published' : 'draft',
          },
        },
      },
      plugins: ['schema-ast'],
    },
  },
};

export default config;

🔗 Source code

The above configuration assumes that you're using a Next.js application where you can use the @next/env package to manage your environment variables. If you're not working with Next.js, you can use the dotenv package or similar to load your environment variables.

Before running the codegen command, make sure to set your STORYBLOK_API_TOKEN in your environment variables. Once that’s done, you can run codegen to generate the schema file:

graphql-codegen

By executing this command, the GraphQL schema from Storyblok will be fetched and stored locally in your project, allowing for a more integrated and efficient development workflow.

Configuring GraphQL Codegen for Storyblok

With the GraphQL schema from Storyblok in hand, the next step is to expand GraphQL codegen configuration. This will enable you to generate type-safe operations and types that correspond with your Storyblok components and queries.

At FocusReactive, we specialize in building high-performance Next.js applications that benefit from static generation for maximum efficiency. Our preferred setup involves fetching data from a CMS at build time, ensuring our static pages are populated with the latest content without compromising on speed.

For Next.js projects, one of the options can be the typescript-graphql-request plugin. Under the hood this plugin works with the graphql-request library — a minimal, flexible, and easy-to-use GraphQL client. With typescript-graphql-request, we generate an SDK that is fully typed and allowing us to make strongly-typed GraphQL requests. This nicely integrates with data fetching in Next.js Server Components, enabling us to pre-render pages with data from Storyblok.

Write sample GraphQL query

Writing a GraphQL query for Storyblok starts with understanding your content types and what data you need to retrieve. Here's a simple example of a GraphQL query to fetch story with a specific content type:

query posts {
  PostItems {
    items {
      uuid
      content {
        body
        intro
        title
      }
    }
  }
}

🔗 Source code

This is what the Post content type looks like inside Storyblok:

To ensure that this query is valid for your Storyblok project, you can test it using GraphiQL, as shown below:

Modify config to target this query

Now, let's adjust the codegen.ts configuration to target the newly created query file:

const config: CodegenConfig = {
  overwrite: true,
  generates: {
    'src/generated/storyblok.graphql': {
      schema: {
        'https://gapi.storyblok.com/v1/api': {
          headers: {
            token: process.env.STORYBLOK_API_TOKEN!,
            version: process.env.NODE_ENV === 'production' ? 'published' : 'draft',
          },
        },
      },
      plugins: ['schema-ast'],
    },

    'src/generated/storyblokSdk.ts': {
      documents: ['src/graphql/**/*.graphql'],
      schema: {
        'https://gapi.storyblok.com/v1/api': {
          headers: {
            token: process.env.STORYBLOK_API_TOKEN!,
            version: process.env.NODE_ENV === 'production' ? 'published' : 'draft',
          },
        },
      },
      plugins: ['typescript', 'typescript-operations', 'typescript-graphql-request'],
    },
  },
};

🔗 Source code

The plugins define the output of the code generation process. You've already included some basic plugins:

typescript - generates TypeScript definitions from your GraphQL schema
typescript-operations - creates TypeScript definitions for your GraphQL queries
typescript-graphql-request - generates a ready-to-use SDK, which is essentially a set of types and functions

Don’t forget to install new packages:

npm i -D @graphql-codegen/typescript-operations @graphql-codegen/typescript-graphql-request

Run codegen

Let’s run codegen again and check the generated output:

graphql-codegen

Now, the generated code should include an SDK. The SDK provides a function for each of your GraphQL query, already typed with the appropriate variables and return types.

For example, alongside the types for your schema, you'll have functions like these:

// src/generated/storyblokSdk.ts

import { GraphQLClient } from 'graphql-request';

export function getSdk(client: GraphQLClient) {
  return {
    posts(variables?: PostsQueryVariables) {
      return client.request(PostsDocument, variables);
    },
    // ... other operations
  };
}

Use the SDK in your application

To use the SDK in your application, create an instance of GraphQLClient and pass it to getSdk:

import { GraphQLClient } from 'graphql-request';
import { getSdk } from './generated/storyblokSdk';

const client = new GraphQLClient('https://gapi.storyblok.com/v1/api', {
  headers: {
    token: process.env.STORYBLOK_API_TOKEN!,
    version: 'draft' // you don't need token when fetch 'published' content
  }
});

export const sdk = getSdk(client);

🔗 Source code

Now, you can use the SDK functions in your components or services:

const PostsPage = async () => {
  const { PostItems } = await sdk.posts();

    // ...
};

🔗 Source code

With graphql-request and the generated SDK, you are now equipped with a powerful, typed layer to make requests to your GraphQL API. This pattern is especially beneficial for projects that may not need the complexity of a more comprehensive solution like Apollo Client but still want to maintain strong typing with minimal overhead.

Advanced techniques and customizations

One nasty aspect of the generated types is that many fields, including essential ones like id and slug, are marked as optional. This often leads to an excess of null-checks in your code, which can be cumbersome. To address this, we can apply a simple hack to simplify working with generated typings:

// ...
'src/generated/storyblokSdk.ts': {
      documents: ['src/graphql/**/*.graphql'],
      schema: {
        'https://gapi.storyblok.com/v1/api': {
          headers: {
            token: process.env.STORYBLOK_API_TOKEN!,
            version: process.env.NODE_ENV === 'production' ? 'published' : 'draft',
          },
        },
      },
      plugins: ['typescript', 'typescript-operations', 'typescript-graphql-request'],
      config: {
        // all fields in the schema are optional
        // but we don't want to check for fields like `slug`
        // so, all the validation lies on the shoulders of devs
        avoidOptionals: true,
        maybeValue: 'T',
      },
    },
// ...

🔗 Source code

With the avoidOptionals option set to true, the generated types will treat fields as non-optional. The maybeValue specifies how nullable values are represented. Below a comparison to illustrate the difference:

This change eliminates many conditional statements but also increases risk, so it should be used wisely. Making fields non-nullable assumes that they will always be present in the response and responsibility of validation shifts more to the development side. Error handling becomes crucial, especially when dealing with dynamic content from the CMS.

Benefits of this integration

Integrating GraphQL Codegen with Storyblok brings several key advantages that can significantly enhance the development process and the overall quality of the project.

Streamlined development process

The automatic generation of types and operations reduces the need for manual updates and lowers the chance for human error. It ensures that developers always have up-to-date code that reflects the current state of the Storyblok content schema.

Automatic typings update after schema changes

Whenever the content schema in Storyblok changes, GraphQL Codegen can
automatically update the typings in your project. This guarantees that the frontend code remains consistent with the backend without requiring any manual intervention.

Enhanced developer experience

Developers can enjoy a more productive workflow with less context switching. They no longer need to manually check the schema or write types by hand. Instead, they can focus on building features and improving the user interface.

Conclusion

In this article, we've explored how GraphQL Codegen can be integrated with Storyblok to improve your development workflow. From setting up and fetching the Storyblok GraphQL schema to generating type-safe code and utilizing a typed SDK, this integration provides a foundation for building dynamic and scalable applications.

Looking forward

As you integrate these tools and practices into your projects, you'll likely find that the initial effort pays off quickly. Your development process becomes more streamlined, you minimize bugs related to data handling, and you can iterate on your components and features much faster.

Invitation to embrace the integration

Embrace the practices outlined in this guide to boost your development speed, improve your code quality, and build a better experience for both developers and end-users.

By following the steps we've discussed, you are well on your way to creating an efficient development environment that leverages the best of GraphQL and Storyblok.

Integrating Sanity's Presentation Tool with Next.js: Comprehensive Guide

Eugene Boruhov — Fri, 22 Dec 2023 00:37:55 +0000

The world of web development is constantly evolving, with new tools and technologies emerging to optimize the content creation and management process. One such tool is the Sanity Presentation Tool, a powerful feature within the Sanity.io ecosystem designed to enhance the content editing experience. This tool bridges the gap between content management and frontend presentation, offering a seamless, real-time editing interface that is invaluable for content creators and developers alike.

While there is exhaustive documentation available, including the template-nextjs-personal-website repository which contains useful code examples, this guide aims to synthesize information from those resources to provide a detailed, practical explanation. Its focus is on demonstrating how to integrate the Sanity Presentation Tool into your existing Next.js application, transforming your content handling into a more dynamic, interactive, and visually intuitive process.

For those new to Sanity or looking to integrate it into their workflow, this guide offers a practical approach to implementing the Presentation Tool. Integrating this tool into your system involves two key components: configuring the Presentation Tool on the Sanity side using the sanity/presentation tool, and enabling live-editing and visual overlays in your frontend application. In this guide, we'll walk through the steps of enabling the Presentation Tool in a Next.js app, focusing on the frontend aspect. For those interested in the Sanity side implementation, I recommend checking out our article A Deep Dive into Sanity's Visual Editing and Presentation Tool: The developer view, which provides a comprehensive overview and practical configuration examples. Additionally, you can see all the code samples from this article in action in our demo project, which showcases all the new features of the Presentation Tool.

Understanding the Presentation Tool
Implementation roadmap
Initial configuration
Setting up loaders
Implementing loaders in components
Enabling overlays
Conclusion

Understanding the Presentation Tool

Before diving into the implementation, it's crucial to understand what the Sanity Presentation Tool is and how it improves the content editing experience. Here, we assume that you are already familiar with the Presentation Tool and will focus more on practical aspects. If you are new to the Presentation Tool, I recommend going through our previous article for a detailed introduction.

The core of the Presentation Tool's functionality lies in its ability to offer a live, interactive preview of content. This feature, as it allows content creators to see and edit content in a format that closely resembles its final presentation on frontend. Such real-time feedback is invaluable in creating a more efficient and error-free editing process.

Central to this tool are several key technologies:

@vercel/stega a technology used for encoding metadata within text strings. This encoding is necessary for linking the frontend content with its corresponding editable segments in the CMS.
@sanity/client/stega integrates Stega with the Sanity client and ensures communication between your content management system and frontend.
@sanity/react-loader facilitates data fetching and streaming in your application, playing a key role in managing content flow and real-time updates.
@sanity/overlays creates a visual editing interface on frontend, allowing users to click and directly edit content.

In the following sections, we will explore how these technologies can be integrated into an existing Next.js application to leverage the full capabilities of the Sanity Presentation Tool.

Implementation roadmap

Embarking on the journey to integrate the Sanity Presentation Tool into a Next.js application requires a strategic approach. This section outlines the roadmap that we will follow to enable the full functionality of the Presentation Tool in your existing Next.js app. By breaking down the process into manageable steps, we aim to provide a clear and concise guide that can be followed with ease, regardless of your experience level.

Setting up the environment: Ensure that your development environment is ready for the integration. This includes having the latest version of Next.js installed and your Sanity Studio set up.
Installation of required packages: We'll cover the necessary packages that need to be installed in your Next.js application to support the Presentation Tool. These include the Sanity client and specific packages like @sanity/react-loader and @sanity/overlays.
Configuring loaders: Loaders play a pivotal role in fetching and rendering content. We will delve into the setup of loaders, discuss their importance, and demonstrate how to use them effectively in your application.
Enabling overlays: Overlays provide the visual interface for editing content directly from the preview. We'll guide you through the process of enabling them in your application.
Live mode and real-time preview: A crucial feature of the Presentation Tool is the real-time preview. We will explore how to enable and make the most of this live mode for immediate content updates.
Final touches: Once all components are in place, we'll go through the process of fine-tuning and testing the integration to ensure everything works as expected.

Initial configuration

Before integrating the Sanity Presentation Tool into your Next.js application, it's essential to ensure your environment is up to date and has all the necessary components. This initial setup lays the groundwork for a smooth integration process.

Updating Sanity: Start by updating your Sanity Studio to version 3.20 or higher. This update ensures that you have access to the latest features we rely on here.
Updating Next.js: Ensure that your Next.js application is running on version 18 or higher. This update is needed for compatibility and taking advantage of the latest Next.js features and performance enhancements.
Installing required packages: With your environment up to date, proceed to install the necessary packages. Use the following commands in your terminal to install these packages:

npm install @sanity/client @sanity/react-loader @sanity/overlays

Alternatively, adjust these commands to suit your preferred package manager, such as Yarn.

With these initial configuration steps complete, your application will be well-prepared for the next stages of integrating the Sanity Presentation Tool.

Setting up loaders

Loaders provide a unified method for loading data from Sanity's Content Lake, ensuring consistency across different states (production, development, and preview) and rendering modes (server and client-side). They are key to implementing Visual Editing capabilities, enabling features like real-time previews and clickable overlays. In this section, we'll delve into setting up Loaders and explore their practical applications. Sanity offers loaders tailored for various frameworks, ensuring compatibility and ease of integration regardless of your project's specific technology stack. For this guide, we will focus on using the React Loader. However, the techniques discussed can be adapted to other frameworks – refer to the documentation for guidance on your framework.

Updating sanity client with stega support

Establish a connection between your Next.js application and your Sanity project using the @sanity/client package. Configure the client with necessary parameters like project ID, dataset, and API version.

If you're currently using @sanity/client or next-sanity, you'll need to switch to @sanity/client/stega. This updated client includes support for Stega, essential for the Presentation Tool's interactive and visual features. The upgrade process is straightforward, in most cases, all you need to do is update your import statement and configure the stega options. Here's how your updated client configuration should look:

// client.ts

import { createClient } from '@sanity/client/stega'

export const client = createClient({
  projectId: "<YOUR_SANITY_PROJECT_ID>",
  dataset: "<YOUR_SANITY_DATASET>",
  apiVersion: "<API_VERSION>",
  useCdn: false, // We will rely on Next.js cache
  perspective: 'published',
  stega: {
    studioUrl: "<SANITY_STUDIO_URL>",
  },
})

Creating a `QueryStore`

Start by setting up a query store using the createQueryStore function from @sanity/react-loader. This store manages the data fetching and streaming in your application. It includes essential utilities like useQuery, loadQuery, and useLiveMode, each serving a specific function:

useQuery react hook for client-side data loading and streaming.
loadQuery used primarily for server-side rendering (SSR) to fetch content data.
useLiveMode activates real-time updates, ensuring that content changes in Sanity are instantly reflected in your application.

// queryStore.ts

import { createQueryStore } from '@sanity/react-loader/rsc'

// The `queryStore` instance is shared in RSC and client components, keep this file tiny as it will be included in the client bundle
export const queryStore = createQueryStore({
  client: false,
  ssr: true,
})

Setting up a wrapper for `loadQuery`

In order to enhance the functionality of loadQuery and handle specific needs such as server-client consistency and effective caching strategies, we create a custom wrapper around this function. Additionally, we will integrate support for draft mode, ensuring that it responds dynamically to different content states in your application.

// Throw error if this file will be imported on the client side
import 'server-only'

import { draftMode } from 'next/headers'

import { client } from './client'
import { queryStore } from './queryStore'

// Configuring a separate client for server-side usage, enabling Stega in non-production environments
const serverClient = client.withConfig({
  stega: {
    enabled: process.env.NODE_ENV !== 'production',
  },
})

// Setting the server client in the query store for consistent server-client data handling
queryStore.setServerClient(serverClient)

// Custom wrapper function for `queryStore.loadQuery` to handle draft mode and keep configuration in one place
export const loadQuery = ((query, params = {}, options = {}) => {
  return queryStore.loadQuery(query, params, {
    cache: 'force-cache',
    perspective: draftMode().isEnabled ? 'previewDrafts' : 'published',
    ...options,
  })
}) satisfies typeof queryStore.loadQuery

Setting up a wrapper for `useQuery`

Creating a custom wrapper around the useQuery hook is an effective way to extend its functionality and tailor it to the specific needs of your application. This wrapper can handle additional tasks like encoding data attributes for overlays and consistent errors managing. Here's how you can set it up:

import {
  type QueryParams,
  useEncodeDataAttribute,
  type UseQueryOptions,
} from '@sanity/react-loader/rsc'

import { queryStore } from './createQueryStore'

// Custom hook for `queryStore.useQuery` to simplify usage of `encodeDataAttribute`
export const useQuery = <
  QueryResponseResult = unknown,
  QueryResponseError = unknown,
>(
  query: string,
  params?: QueryParams,
  options?: UseQueryOptions<QueryResponseResult>,
) => {
  const snapshot = queryStore.useQuery<QueryResponseResult, QueryResponseError>(
    query,
    params,
    options,
  )

  // Generate data attributes for overlays using Sanity's data
  const encodeDataAttribute = useEncodeDataAttribute(
    snapshot.data,
    snapshot.sourceMap,
    '<YOUR_STUDIO_URL>',  // Replace with your Sanity Studio URL
  )

  // Consistent error handling by throwing any caught errors
  if (snapshot.error) {
    throw snapshot.error
  }

  // Return the query results along with the `encodeDataAttribute` function
  return {
    ...snapshot,
    encodeDataAttribute,
  }
}

// Export `useLiveMode` for enabling real-time updates in the `VisualEditing` component
export const { useLiveMode } = queryStore

Along with data from queryStore.useQuery, our hook also returns the encodeDataAttribute function. This function is used to create the necessary data for the data-sanity attribute, which we will discuss in more detail below.

Implementing loaders in components

Integrate Loaders into your Next.js components using the useQuery and loadQuery hooks. For server-side rendered pages, use loadQuery to fetch initial data. For dynamic, client-side interactions, useQuery is your go-to hook. This ensures that your components are always displaying up-to-date content from Sanity.

Creating a preview component for Next.js routes

Begin by developing a client-side component, designated for loading only when the draft mode is enabled. The purpose of this component is to fetch and pass the most current, or 'fresh', data to your page, ensuring that the content being edited is up-to-date with the latest changes made in the Sanity Studio.

'use client'

import { type QueryResponseInitial } from '@sanity/react-loader/rsc'

import Page from './Page'
import { useQuery } from './useQuery'

type Props = {
  params: { slug: string }
  initial: QueryResponseInitial<PagePayload | null>
}

export default function PagePreview(props: Props) {
  const { params, initial } = props
  // Using the `useQuery` hook to fetch the most current data based on the page slug
  const { data } = useQuery<'YOUR_PAGE_PAYLOAD_TYPE' | null>('<YOUR_GROQ_QUERY>', params, {
    initial,
  })

  return <Page data={data!} />
}

Use the preview component

With the preview component set up, let's now integrate it into a Next.js page:

import dynamic from 'next/dynamic'
import { draftMode } from 'next/headers'
import { notFound } from 'next/navigation'

import { Page } from './Page'
import { loadQuery } from './loadQuery'

// 1. Lazily load the Preview component for performance optimization
const PagePreview = dynamic(() => import('./PagePreview'))

type Props = {
  params: { slug: string }
}

export default async function PageRoute({ params }: Props) {
  // 2. Fetch initial data for the page
  const initial = await loadQuery(params.slug)

  // 3. Display the Preview component in draft mode with initial data
  if (draftMode().isEnabled) {
    return <PagePreview params={params} initial={initial} />
  }

  // Handle page not found scenario
  if (!initial.data) {
    return notFound()
  }

  // Render the standard page with fetched data
  return <Page data={initial.data} />
}

Dynamic loading: The PagePreview component is dynamically imported using dynamic function. This approach optimizes performance by only loading the component when necessary, specifically in draft mode for content editing.
Server-side data fetching: The loadQuery function fetches initial data. Depending on the mode (draft or production), it provides the appropriate data to either the preview or standard page component.
Draft mode check: The use of draftMode().isEnabled ensures that VisualEditing is only rendered when the application is in draft mode. This is crucial for maintaining performance and user experience in the production environment.

Using `useQuery` in production

While the useQuery function is primarily used in the context of editing and development, it's worth noting that it can also be employed in a production environment. Utilizing useQuery in production allows for the creation of highly dynamic components. However, this is a rarer use case, as it involves real-time updates and data streaming.

'use client';

import { useQuery } from './useQuery'

export function DocumentCount() {
  const { data, loading } = useQuery<number>('count(*)')

  if (loading) {
    return <div>Loading…</div>
  }

  return <div>Total # of documents: {data}</div>
}

By carefully implementing these steps, you ensure that your Next.js application not only efficiently manages content in both production and draft modes but also leverages the full potential of Sanity's real-time content editing features.

Enabling overlays

With the Loaders set up, the next crucial step in integrating the Sanity Presentation Tool into your Next.js application is implementing overlays. They appear as clickable visual indicators on the frontend, guiding content creators directly to editable elements. When an overlay is clicked, it signals the Sanity Studio to open the corresponding field for editing, even if it's nested deeply within the document structure.

Creating the `VisualEditing` component

Start by creating a VisualEditing component. This component will incorporate the useLiveMode hook from @sanity/react-loader and enableOverlays function from @sanity/overlays:

'use client'

import { enableOverlays } from '@sanity/overlays'
import { useEffect } from 'react'

import { client } from './client'
import { useLiveMode } from './useQuery'

// Configure the client to always use Stega in Live Mode
const stegaClient = client.withConfig({ stega: true })

// Set the allowed studio origin, defaulting to localhost in a non-browser environment
const allowStudioOrigin =
  typeof location === 'undefined' ? 'http://localhost:3000' : location.origin

export default function VisualEditing() {
  useEffect(() => {
    // Enable overlays and set up a cleanup function
    const disable = enableOverlays({ allowStudioOrigin })

    return () => disable()
  }, [])

  // Activate live mode updates using the configured client
  useLiveMode({ allowStudioOrigin, client: stegaClient })

  return null
}

useLiveMode hook is essential for reflecting any changes made in the Sanity Studio onto the frontend preview instantaneously. This real-time update capability is crucial for maintaining synchronization between the content in the CMS and its presentation.
enableOverlays function is responsible for turning on the overlay functionality in your application.

Adding `VisualEditing` component to your layout

Integrate the VisualEditing component into your application's layout. This ensures that the live preview and overlay functionality are available across all pages.

import dynamic from 'next/dynamic'
import { draftMode } from 'next/headers'

// Dynamically import the VisualEditing component for optimized loading
const VisualEditing = dynamic(() => import('./VisualEditing'))

export default function IndexRoute({
  children,
}: {
  children: React.ReactNode
}) {
  return (
    <>
      {/* ... */}

      {/* Conditionally render the VisualEditing component based on draft mode */}
      {draftMode().isEnabled && <VisualEditing />}
    </>
  )
}

In the example above, we load VisualEditing dynamically, in the same way, we did previously with PreviewPage, and render it only when in draft mode. This approach optimizes performance by only loading the component when necessary, specifically in draft mode for content editing.

Integrating overlays into your application

Ensure that your content elements have the necessary data attributes for overlays to recognize and interact with them. This is particularly important for custom components or more complex content structures where stega strings don't work.

Consider a scenario where you want to add an overlay around a non-text element. For such components, you can use the data-sanity attribute. In the example below we have two components: SvgIcon and Header. SvgIcon is a hardcoded component stored in a repository. isLogoEnabled is boolean option coming from the CMS to determine visibility of SvgIcon. To enable overlays for SvgIcon with the link to isLogoEnabled you need to:

Pass down the encodeDataAttribute from our custom useQuery hook in the PreviewPage component.
Add the data-sanity attribute and use the encodeDataAttribute function to generate a string containing the data necessary for overlays to open the correct field in the CMS. This function requires the path to the isLogoEnabled field as an argument.

// PreviewPage.tsx
export default function PagePreview(props: Props) {
  const { params, initial } = props
  const { data, encodeDataAttribute } = useQuery<PagePayload | null>(pagesBySlugQuery, params, {
    initial,
  })

  return <Page data={data!} encodeDataAttribute={encodeDataAttribute} />
}

// SvgIcon.tsx
import { SVGProps } from 'react'

export const SvgIcon = (props: SVGProps<SVGSVGElement>) => {
  return (
    <svg viewBox="0 0 170 61" width="170px" height="61px" {...props}>
      <path
        fillRule="evenodd"
        fill="rgb(248, 248, 248)"
        d="M14.959,59.996 L7.050,50.543 L5.742,50.543 L5.742,60.004 L0.001,60.004 L0.001,38.907 L5.141,32.341 L11.488,32.341 C13.715,32.341 15.740,32.999 17.346,34.267 C18.928,35.514 20.048,37.304 20.501,39.587 C20.841,41.305 20.739,43.079 20.178,44.682 C19.621,46.273 18.632,47.699 17.196,48.758 L17.193,48.753 C16.386,49.357 15.482,49.809 14.511,50.106 C14.425,50.132 14.338,50.156 14.250,50.180 L22.463,59.996 L14.959,59.996 ZM60.938,59.996 L54.403,41.742 L47.719,59.996 L41.608,59.996 L51.737,32.328 L57.120,32.352 L67.017,59.996 L60.938,59.996 ZM39.473,59.996 L24.161,59.996 L24.141,39.082 L29.282,32.340 L40.017,32.340 L40.017,38.158 L32.080,38.158 L29.862,41.065 L29.864,43.516 L39.473,43.516 L39.473,49.334 L29.869,49.334 L29.874,54.177 L39.473,54.177 L39.473,59.996 ZM151.154,32.349 L141.283,60.001 L135.901,60.001 L126.063,32.349 L132.138,32.349 L138.596,50.502 L145.076,32.349 L151.154,32.349 ZM99.694,59.994 L99.694,38.144 L91.008,38.144 L91.008,32.340 L114.121,32.340 L114.121,38.144 L105.436,38.144 L105.436,59.994 L99.694,59.994 ZM117.375,59.992 L117.375,32.341 L123.117,32.341 L123.117,59.992 L117.375,59.992 ZM169.446,59.999 L151.752,59.999 L151.732,39.079 L156.899,32.340 L169.994,32.340 L169.994,38.128 L159.696,38.128 L157.453,41.054 L157.456,43.532 L169.446,43.532 L169.446,49.320 L157.461,49.320 L157.466,54.210 L169.446,54.210 L169.446,59.999 ZM115.889,5.979 L107.795,5.979 C106.298,5.979 103.601,6.732 103.620,8.593 C103.645,11.060 106.281,11.082 108.192,11.275 C109.686,11.427 111.464,11.623 113.132,12.294 C115.245,13.145 116.982,14.627 117.576,17.321 C118.274,20.479 117.264,23.409 114.756,25.464 C112.847,27.029 110.255,27.845 107.860,27.845 L99.766,27.845 L99.766,22.061 L107.860,22.061 C109.308,22.061 111.747,21.551 112.021,19.650 C112.128,18.909 111.908,18.013 111.002,17.649 C110.058,17.269 108.743,17.126 107.631,17.015 C104.104,16.657 100.180,15.881 98.570,12.249 C97.799,10.512 97.684,8.261 98.231,6.441 C99.476,2.308 103.736,0.196 107.795,0.196 L115.889,0.196 L115.889,5.979 ZM79.119,0.190 L79.120,18.940 C79.120,19.797 79.508,20.465 80.090,20.938 C81.007,21.683 82.350,22.058 83.655,22.058 L83.655,22.068 L89.336,22.067 L89.336,0.190 L95.077,0.190 L95.077,27.846 L83.655,27.850 L83.655,27.861 C81.159,27.861 78.478,27.056 76.502,25.450 C74.630,23.928 73.379,21.757 73.379,18.940 L73.379,0.190 L79.119,0.190 ZM0.000,27.846 L0.000,6.892 L5.273,0.190 L16.235,0.190 L16.235,6.001 L8.026,6.001 L5.741,8.905 L5.741,11.640 L14.981,11.640 L14.981,17.445 L5.741,17.445 L5.741,27.846 L0.000,27.846 ZM37.817,8.272 C36.360,6.798 34.346,5.887 32.122,5.887 C31.434,5.887 30.792,5.964 30.202,6.109 C29.773,6.214 29.346,6.363 28.927,6.549 L24.193,12.559 C24.108,13.074 24.068,13.494 24.068,14.029 C24.068,16.278 24.970,18.313 26.427,19.786 C27.884,21.258 29.898,22.170 32.122,22.170 C34.346,22.170 36.360,21.258 37.817,19.786 C39.275,18.313 40.176,16.277 40.176,14.029 C40.176,11.780 39.275,9.744 37.817,8.272 ZM32.122,-0.015 C35.958,-0.015 39.431,1.558 41.944,4.099 C44.458,6.640 46.014,10.151 46.014,14.029 C46.014,17.906 44.458,21.417 41.944,23.958 C39.431,26.499 35.958,28.072 32.122,28.072 C28.287,28.072 24.813,26.499 22.300,23.958 C18.427,20.043 17.520,15.093 18.838,9.903 L25.182,1.849 C26.408,1.204 27.471,0.728 28.834,0.392 C29.912,0.126 31.015,-0.015 32.122,-0.015 ZM70.110,27.844 C67.384,27.844 64.562,27.902 61.861,27.839 C58.215,27.753 54.921,26.222 52.518,23.792 C50.042,21.290 48.511,17.833 48.511,14.016 C48.511,10.198 50.042,6.741 52.518,4.237 C54.993,1.736 58.412,0.188 62.189,0.188 L70.110,0.188 L70.110,5.992 L62.189,5.992 C59.997,5.992 58.013,6.890 56.576,8.341 C55.141,9.793 54.252,11.800 54.252,14.016 C54.252,16.232 55.141,18.237 56.576,19.690 C57.675,20.799 59.094,21.585 60.681,21.895 C61.842,22.119 63.215,22.051 64.391,22.050 L70.109,22.050 L70.110,27.844 ZM87.754,59.997 C85.028,59.997 82.207,60.055 79.506,59.991 C75.859,59.906 72.565,58.375 70.162,55.945 C67.686,53.442 66.156,49.984 66.156,46.168 C66.156,42.350 67.686,38.892 70.162,36.390 C72.637,33.888 76.056,32.340 79.833,32.340 L87.754,32.340 L87.754,38.144 L79.833,38.144 C77.641,38.144 75.657,39.041 74.221,40.494 C72.785,41.945 71.897,43.951 71.897,46.168 C71.897,48.383 72.785,50.390 74.221,51.842 C75.319,52.951 76.738,53.738 78.325,54.046 C79.486,54.271 80.860,54.203 82.036,54.203 L87.754,54.202 L87.754,59.997 ZM5.742,44.703 L11.495,44.703 C12.004,44.703 12.468,44.641 12.874,44.518 C13.235,44.406 13.551,44.253 13.810,44.058 L13.832,44.036 C14.283,43.703 14.596,43.250 14.773,42.743 C14.992,42.118 15.030,41.414 14.894,40.727 C14.730,39.899 14.359,39.277 13.847,38.874 C13.268,38.417 12.452,38.181 11.488,38.181 L7.894,38.181 L5.742,40.929 L5.742,44.703 Z"
      ></path>
    </svg>
  )
}

// Header.tsx
import type { EncodeDataAttributeCallback } from '@sanity/react-loader/rsc'
import { SvgIcon } from './SvgIcon'

interface HeaderProps {
  // ...
  encodeDataAttribute?: EncodeDataAttributeCallback
}

export function Header({ encodeDataAttribute, ...props }: HeaderProps) {
  return (
    <header>
      {/* ... */}

      <SvgIcon
        data-sanity={encodeDataAttribute?.(['header', 'isLogoEnabled'])}
      />
    </header>
  )
}

Enhancing navigation within Presentation Tool

To ensure smooth navigation within the Sanity Presentation Tool, we utilize a HistoryAdapter. This adapter maintains synchronization between the studio preview pane and your application’s routing or history state. It effectively manages navigation events and updates, ensuring that changes in your application's URL or state are accurately reflected in the Studio's preview environment and vice versa.

export default function VisualEditing() {
  const router = useRouter()
  const pathname = usePathname()
  const searchParams = useSearchParams()
  const routerRef = useRef(router)
  const navigateRef = useRef<HistoryAdapterNavigate>()

  routerRef.current = router

  const history: HistoryAdapter = useMemo(
    () => ({
            // Subscribe function to handle navigation changes
      subscribe(navigate) {
        navigateRef.current = navigate
        return () => {
          navigateRef.current = undefined
        }
      },

            // Update function to handle different types of history updates
      update(update) {
        switch (update.type) {
          case 'push':
            return routerRef.current.push(update.url)
          case 'pop':
            return routerRef.current.back()
          case 'replace':
            return routerRef.current.replace(update.url)
          default:
            throw new Error(`Unknown update type: ${update.type}`)
        }
      },
    }),
    [],
  )

  useEffect(() => {
    const disable = enableOverlays({
      allowStudioOrigin,
      history,
    })
    return () => disable()
  }, [])

  // Update navigation state when pathname or search parameters change
  useEffect(() => {
    navigateRef.current?.({
      type: 'push',
      url: `${pathname}${searchParams?.size ? `?${searchParams}` : ''}`,
    })
  }, [pathname, searchParams])

  useLiveMode({ allowStudioOrigin, client: stegaClient })

  return null
}

Conclusion

As we reach the end of this guide, you should now have a fully functional integration of the Sanity Presentation Tool in your Next.js application. This integration not only enhances the content management experience but also brings a new level of interactivity and efficiency to your workflow.

Reflecting on the benefits

The integration of the Presentation Tool offers numerous advantages:

Real-time editing: Content creators can see changes instantly, making the editing process more intuitive and efficient.
Visual clarity: Overlays offer a clear visual indication of editable content, simplifying content management.
Enhanced user experience: The seamless integration between the frontend and the CMS improves the overall user experience, both for content creators and developers.

Encouragement to experiment

With the foundational knowledge and examples provided in this guide, you're encouraged to experiment further. Each Next.js application is unique, and there may be additional ways to tailor the Presentation Tool to better suit your specific needs. If you find yourself in need of expert advice on Headless CMS and the latest web technologies, don't hesitate to get in touch with us.

Seeking further assistance

For additional resources or support, consider exploring the Sanity community forums or reaching out to fellow developers. The open-source nature of these tools means that there is a wealth of shared knowledge and experience available.

Final thoughts

Integrating the Sanity Presentation Tool into your Next.js application is a step towards a more dynamic and interactive web development experience. As technology continues to evolve, staying adaptable and open to new tools and methodologies will undoubtedly benefit your projects and workflow.

We hope this guide has been valuable in your journey to enhance your Next.js application with the Sanity Presentation Tool. Happy coding!

Forem: Eugene Boruhov

Automating your content with Sanity's Agent Actions, Functions & Blueprints

AI & Automation Inside Sanity

Agent Actions

Functions & Blueprints

Functions CLI

Automation with GROQ Delta Functions

Infrastructure as Code with Blueprints

From Theory to Practice

FAQ Schema

Custom Studio Action

Triggering on Publish

Deploy and Go

Conclusion

Integrating GraphQL Codegen with Storyblok: Step-by-Step Guide

Table of contents

Viewing and fetching the Storyblok GraphQL schema

Installation

Initial codegen configuration

Configuring GraphQL Codegen for Storyblok

Write sample GraphQL query

Modify config to target this query

Run codegen

Use the SDK in your application

Advanced techniques and customizations

Benefits of this integration

Streamlined development process

Automatic typings update after schema changes

Enhanced developer experience

Conclusion

Looking forward

Invitation to embrace the integration

Integrating Sanity's Presentation Tool with Next.js: Comprehensive Guide

Table of Contents

Understanding the Presentation Tool

Implementation roadmap

Initial configuration

Setting up loaders

Updating sanity client with stega support

Creating a QueryStore

Setting up a wrapper for loadQuery

Setting up a wrapper for useQuery

Implementing loaders in components

Creating a preview component for Next.js routes

Use the preview component

Using useQuery in production

Enabling overlays

Creating the VisualEditing component

Adding VisualEditing component to your layout

Integrating overlays into your application

Enhancing navigation within Presentation Tool

Conclusion

Reflecting on the benefits

Encouragement to experiment

Seeking further assistance

Final thoughts

Creating a `QueryStore`

Setting up a wrapper for `loadQuery`

Setting up a wrapper for `useQuery`

Using `useQuery` in production

Creating the `VisualEditing` component

Adding `VisualEditing` component to your layout