How to preview title instead of value in string options list?
I can see exactly what you're running into! The short answer is: the title from string list options is not stored in your documents – only the value is saved. This means you can't directly access the title in previews or on the front-end without mapping it yourself.
Looking at your projectMember example, when you save roles like ['content', 'director'], that's literally what gets stored in the database. The titles ("Content Designer", "Director") are just UI labels for the Studio interface.
Solutions
1. Map values to titles in the prepare function
You can create a mapping object to convert values back to titles:
preview: {
select: {
personName: 'person.name',
roles: 'roles',
media: 'person.image'
},
prepare(data) {
const roleMap = {
content: 'Content Designer',
director: 'Director',
engineer: 'Engineer',
engineeringManager: 'Engineering Manager',
designer: 'Product Designer',
manager: 'Product Manager',
sme: 'Subject Matter Expert',
technicalWriter: 'Technical Writer',
researcher: 'UX Researcher'
}
return {
...data,
title: data.personName,
subtitle: data.roles && data.roles.map(role => roleMap[role]).join(' / ')
}
}
}2. Use the same mapping on the front-end
In your Gatsby (or any front-end) code, you'll need the same mapping logic:
const roleMap = {
content: 'Content Designer',
director: 'Director',
// ... etc
}
const displayRoles = roles.map(role => roleMap[role])3. Alternative: Use human-readable values
If you don't need the short values for anything specific (like CSS classes or API keys), you could just use human-readable strings as both the title AND value:
options: {
layout: 'radio',
list: [
{title: 'Content Designer', value: 'Content Designer'},
{title: 'Director', value: 'Director'},
// or even simpler:
'Content Designer',
'Director',
'Engineer'
]
}This way, the readable text gets stored directly and you don't need mapping logic anywhere.
Why it works this way
As mentioned in the preview configuration documentation, title values in list options are UI-only and not stored in the database. This is by design – it keeps your data layer clean and allows you to change UI labels without migrating data.
The trade-off is that you need to maintain the mapping in your code, but this gives you flexibility to display different labels in different contexts (Studio vs. front-end, different languages, etc.).
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.