TypeScript error with react-portabletext block components in NextJS
This is a TypeScript type inference issue with @portabletext/react. The error occurs because TypeScript can't properly infer the component prop types when you define the components object inline without explicit typing.
The solution is to explicitly type your components object using the PortableTextReactComponents type from the library:
import { PortableText, PortableTextReactComponents } from "@portabletext/react";
const components: Partial<PortableTextReactComponents> = {
block: {
h1: ({children}) => <h1 className="text-2xl">{children}</h1>,
}
};
<PortableText value={body} components={components} />By adding the type annotation Partial<PortableTextReactComponents>, you're explicitly telling TypeScript what structure to expect, which resolves the type incompatibility error.
Why This Happens
The issue stems from how TypeScript infers types. When you define the components object without explicit typing, TypeScript infers that children is required based on your component signature ({children}) => .... However, the actual PortableTextComponentProps type from the library makes children optional, creating a type mismatch.
The Partial<PortableTextReactComponents> type tells TypeScript to expect the proper component structure where all props (including children) follow the library's type definitions.
Alternative Approaches
You can also be more specific about the props if you need access to other properties:
import type { PortableTextBlockComponent } from "@portabletext/react";
const components = {
block: {
h1: ((props) => <h1 className="text-2xl">{props.children}</h1>) as PortableTextBlockComponent,
}
};This pattern is particularly useful when you need to access the full value prop or other properties passed to your custom components, as documented in the @portabletext/react documentation.
The front-end renders fine locally because JavaScript doesn't enforce these type constraints at runtime—it's purely a TypeScript compile-time issue that prevents your Vercel build from succeeding. Adding the explicit type annotation resolves the build failure without changing any runtime behavior.
Show original thread1 reply
Sanity – Build the way you think, not the way your CMS thinks
Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.