Typing context.parent in Sanity custom validation

9 replies
Last updated: May 23, 2023
Hello! just wondering if there’s a correct way to type
context.parent
when writing custom validation as it returns the
unknown
type by default. Thank you!
AI Update

When writing custom validation in Sanity, context.parent returns the unknown type by default, which is intentional since TypeScript can't automatically infer the parent's structure. The solution is to manually type it using a TypeScript type assertion with the as keyword.

Here's the recommended approach:

type ParentContext = {
  parent: {
    // Define the structure of your parent object
    fieldName: string
    anotherField: number
    // ... other fields
  }
}

defineField({
  name: 'myField',
  type: 'string',
  validation: (rule) => rule.custom((value, context) => {
    const { parent } = context as ParentContext
    const { fieldName } = parent
    
    // Now you have proper typing for parent fields
    if (parent.fieldName === 'something') {
      return 'Validation error message'
    }
    
    return true
  })
})

Unfortunately, there isn't a built-in Sanity type that automatically infers the parent structure. The parent property is typed as unknown because Sanity can't know the specific schema structure at compile time. This means you'll need to manually define the type based on your schema.

Why this approach works:

  • The as keyword is a TypeScript type assertion that tells the compiler to treat context as having your defined structure
  • You define the exact shape of the parent object based on your schema
  • This gives you full type safety and autocomplete for parent fields

If you're working with generated TypeScript types from your schema using Sanity TypeGen, you can reference those types in your validation context definition to keep things in sync. This is the cleanest approach since your parent types will automatically update when your schema changes.

As discussed in this community thread, this is the standard pattern for handling typing in custom validation rules where you need access to parent or document context. While it would be nice if IDEs could automatically understand Sanity schemas and provide this typing, for now manual type definitions are the way to go.

Show original thread
9 replies
Looks like it should be the type of the data for the field you're validating, which would be sensible, and looks correct for the example here: https://www.sanity.io/docs/validation#091e10f957aa
Looks like it should be the type of the data for the field you're accessing, doesn't it?
And then you can assign that type to the value you pull out of context.

In looking at your code, presumably the parent has an array field, actually, since you're interested if there would be more than one image ii nit, which doesn't seem it would be named 'image'?

And then you'd be checking for arrayField.length > 1, or maybe testing further using something like arrayField.reduce to count items of a certain type, etc.?

So if you're having a problem where types might help, may want to consider these also.

Hope I understood your question ,
user G
This seems it works well for the typing issue -- I always want to test, when it's Typescript involved....
type aContext = {
  parent: {
    name: string
  }
}

 rule.custom((value, context) => {
          
          const { parent } = context as aContext
          const { name } = parent
          console.log ('parent name: ' + name)

   ...
The
as
is a Typescript cast -- as you can't just redefine an
any
variable. Pretty handy, here anyway....
Thanks for your help! This is what I ended up doing as well. I was just wondering if there’s something built-in to Sanity that allows me to automatically infer types for the specific field under the parent.
I guess it isn’t possible for Sanity to know, hence what parent is typed as
unknown
and we’d just need to type it manually
Great -- and as far as automatic function, not immediately imagining how it could act in time for Typescript to see it, unless it was really an intelligent editor that did this for you, and wrote it in.
I suspect for that, we may live in hope, as someone once said!
really appreciate your help!
most welcome, Ryan 🙂
(and actually the WebStorm I'm using could have the knowledge, I think, if it understood Sanity schemas. Which when we use the defineXXX, it at least comes close...

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.

Was this answer helpful?