Get help on Discord

How to reuse predefined option lists across multiple Sanity schemas?

5 replies
Last updated: Nov 29, 2025
Hey there! I’m stuck with this, maybe somebody is able to give me a hint?

export default {
  name: "platformFeature",
  title: "Plattform Features",
  description: "Ein Feature der Plattform",
  type: "object",
  fields: [
    {
      name: "icon",
      title: "Icon",
      description: "Ein passendes Icon",
      type: "image",
    },
    {
      name: "component",
      title: "Plattform Komponente",
      description: "Zu welcher Komponente gehört dieses Feature?",
      type: "string",
      options: {
        list: [
          { title: "Meeting", value: "meeting" },
          { title: "Player", value: "player" },
          { title: "Server", value: "server" },
          { title: "Collector", value: "collector" },
          { title: "Pro", value: "pro" },
        ],
      },
    },
    {
      name: "heading",
      title: "Feature Heading",
      description: "Ein aussagekräftiger Titel des Features",
      type: "string",
    },
    {
      name: "description",
      title: "Beschreibung",
      description: "Beschreibe das Feature in wenigen Worten",
      type: "text",
    },
  ],
};
This is an 
platformFeature
object I’m working on. A 
platformComponent
can have 
n
features, a 
platformFeature
can have one 
platformComponent
. The user can select a 
component
from a list of options (see 
name: "component"
).
If I’m
hardcoding the values in the schema above it works fine. But I’d like to outsource those options to a separate schema file because there will be other contents that will have a 
component
value (e.g. product pages, help/blog articles, subject in a contact form etc.). DRY, you know…
The 
component
value will not be documents but predefined values the content editor can choose from. How can I include this list of values? I can’t wrap my head around it at the moment.
AI Update

I can help you with this! You're looking to share a list of options across multiple schema fields to keep your code DRY. Here are a few approaches:

Create a separate file for your shared values:

// schemas/constants/platformComponents.js
export const PLATFORM_COMPONENTS = [
  { title: "Meeting", value: "meeting" },
  { title: "Player", value: "player" },
  { title: "Server", value: "server" },
  { title: "Collector", value: "collector" },
  { title: "Pro", value: "pro" },
];

Then import and use it in your schema:

// schemas/platformFeature.js
import { PLATFORM_COMPONENTS } from './constants/platformComponents';

export default {
  name: "platformFeature",
  title: "Plattform Features",
  description: "Ein Feature der Plattform",
  type: "object",
  fields: [
    // ... other fields
    {
      name: "component",
      title: "Plattform Komponente",
      description: "Zu welcher Komponente gehört dieses Feature?",
      type: "string",
      options: {
        list: PLATFORM_COMPONENTS,
      },
    },
    // ... other fields
  ],
};

2. Create a reusable field definition

You can also create a reusable field definition function:

// schemas/fields/componentField.js
import { PLATFORM_COMPONENTS } from '../constants/platformComponents';

export const componentField = (overrides = {}) => ({
  name: "component",
  title: "Plattform Komponente",
  description: "Zu welcher Komponente gehört dieses Feature?",
  type: "string",
  options: {
    list: PLATFORM_COMPONENTS,
  },
  ...overrides,
});

Then use it like this:

import { componentField } from './fields/componentField';

export default {
  name: "platformFeature",
  // ...
  fields: [
    // ... other fields
    componentField(),
    // Or with custom overrides:
    componentField({ validation: Rule => Rule.required() }),
  ],
};

3. For TypeScript users

If you're using TypeScript, you can also type your constants:

// schemas/constants/platformComponents.ts
export const PLATFORM_COMPONENTS = [
  { title: "Meeting", value: "meeting" },
  { title: "Player", value: "player" },
  { title: "Server", value: "server" },
  { title: "Collector", value: "collector" },
  { title: "Pro", value: "pro" },
] as const;

export type PlatformComponent = typeof PLATFORM_COMPONENTS[number]['value'];

The first approach (exporting constants) is the simplest and most common pattern. It keeps your code DRY while being easy to maintain - you only update the list in one place, and all schemas using it will automatically reflect the changes. This works great for your use case where you need the same component options in multiple places like product pages, blog articles, and contact forms!

Show original thread
5 replies

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.

Get started for freeExplore the demo

Was this answer helpful?