Discussion on async schemas and validation functions in Sanity.io

20 replies
Last updated: May 13, 2020
Can
string
type
list
be a promise?
AI Update

Based on the context of your question, I believe you're asking whether the list property on a string field (which defines dropdown/select options) can be a promise or async function.

No, the list property cannot be a promise. The list property in Sanity schema definitions must be either:

  1. An array of strings or objects:
defineField({
  name: 'category',
  type: 'string',
  options: {
    list: ['news', 'blog', 'tutorial']
    // or
    // list: [
    //   {title: 'News', value: 'news'},
    //   {title: 'Blog', value: 'blog'}
    // ]
  }
})
  1. A synchronous function that returns an array:
defineField({
  name: 'category',
  type: 'string',
  options: {
    list: () => ['news', 'blog', 'tutorial']
  }
})

The schema definition in Sanity is evaluated synchronously when Studio loads, so promises and async functions aren't supported in the list property.

Workarounds for dynamic options:

If you need to load options dynamically from an API or database, you have a few alternatives:

  1. Create a separate document type for your options and use a reference field instead of a string list
  2. Use a custom input component that fetches options asynchronously and renders them as a dropdown
  3. Pre-populate options during your build/deploy process and include them in your schema definition

The custom input component approach gives you the most flexibility - you can fetch data when the component mounts and present it to users while still storing the value as a string field.

Hi User, if I recall correctly async schemas are not supported yet, unfortunately. One workaround would be using a custom input component in this case, but that does involve some extra effort.
Hi User, if I recall correctly async schemas are not supported yet, unfortunately. One workaround would be using a custom input component in this case, but that does involve some extra effort.
Now that's a concise description! Yeah, makes sense.
Got a little caught up that we define validations alongside the schema (IN THE SCHEMA FILE) that support Promises...
Concise but in need of elaboration? 😉
Indeed, Promises are supported in validation functions and a few other places. I can see how that is confusing. Hopefully we can expand support for them across the board soon AND improve our docs in the meantime, so you won’t have to find out by trial and error.
Never had seen the definition "async schemas are not supported".
Just that there's not a clear border within the schema files where it's actual schema and where those are studio-only enhancements.
But the notation of "async schemas are not supported" really answers whole lot more to me.
Thanks!
That’s because it’s nowhere right now, I think. Will draft up a ‘Gotcha’ on this to include in the docs. And don’t forget about the option to use a custom input component to achieve the above.
Yeah, I know about the option. The effort is tenfold though.
Absolutely. I might work on some recipes for these in the next two weeks to make this easier to just grab and run with.
I'm mentoring a project currently.Just doing the overall guidance not getting deep down into implementation.

So to speak, I'm puppet-master for now.
Am leading a team with 0 previous experience through an asteroid field of learning React, Next.js, Sanity and other tools along the way while working on a production project. I am doing the absolute practical minimum to get the ship going.

I can steer them, I do lessons in-between the PR's, provide resources, fill holes when they're ready etc.

But we're now only in React shenanigans. It doesn't pay off yet for them to start tinkering with the deep customization options of Sanity. Neither the client is paying for that atm.
So the effort isn't in the sense of actual implementation details, but in the scalability of where we're currently at with the project. 😉
Recipe is good, installable plugin would be awesome! (While I understand that it could shard the hell out of the Sanity landscape)
Whew, that sounds like an intense assignment if it also includes learning React for example - JS as well? 😄 Fun stuff. With regard to the latter, I’ll say this very quietly, but a plugin in this direction might be on its way indeed🤞
It does pack a transition from jQuery era of JS to this new React/webpack/babel era.
People were amazed by native promises, let alone async/await.
Spread operators, destructuring. const/let.
SSR/SSG... a whole new world for peeps over here! 🙂
But we're doing more than OK, I guess I have a knack for putting people on new tracks.
Not to take anything away from the peeps - they're good bunch of developers, just that they were stuck in the old days.

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?