Should Different Sections be Separate Objects which Equate to Props in React?

5 replies

Last updated: Jun 8, 2022

So I’m working on a pretty verbose design for blog posts. There will be full size image sections, text with image on the left, text with image on the right, block quotes, ctas, etc. I’m assuming each of these should be an “object” with different fields which equate to props in react? And then in the document, I should just accept an array of objects?

AI Update

You're on the right track! Yes, using an array of objects where each object represents a different section type is exactly how you'd approach this in Sanity. This pattern is called Block Content or modular content, and it's one of Sanity's strengths.

Here's how it works:

Array of Objects Approach

Define your blog post schema with an array field that accepts different object types:

defineField({
  name: 'content',
  type: 'array',
  of: [
    {
      type: 'object',
      name: 'fullWidthImage',
      fields: [
        {name: 'image', type: 'image'},
        {name: 'alt', type: 'string'}
      ]
    },
    {
      type: 'object',
      name: 'textWithImageLeft',
      fields: [
        {name: 'text', type: 'text'},
        {name: 'image', type: 'image'}
      ]
    },
    {
      type: 'object',
      name: 'textWithImageRight',
      fields: [
        {name: 'text', type: 'text'},
        {name: 'image', type: 'image'}
      ]
    },
    {
      type: 'object',
      name: 'blockQuote',
      fields: [
        {name: 'quote', type: 'text'},
        {name: 'author', type: 'string'}
      ]
    },
    {
      type: 'object',
      name: 'cta',
      fields: [
        {name: 'heading', type: 'string'},
        {name: 'buttonText', type: 'string'},
        {name: 'link', type: 'url'}
      ]
    }
  ]
})

Rendering in React

Each object in the array maps perfectly to React components. You'd query the data and map over the array:

{post.content?.map((block) => {
  switch(block._type) {
    case 'fullWidthImage':
      return <FullWidthImage key={block._key} {...block} />
    case 'textWithImageLeft':
      return <TextImageLeft key={block._key} {...block} />
    case 'textWithImageRight':
      return <TextImageRight key={block._key} {...block} />
    case 'blockQuote':
      return <BlockQuote key={block._key} {...block} />
    case 'cta':
      return <CTA key={block._key} {...block} />
    default:
      return null
  }
})}

Mixing with Rich Text

You can also include Portable Text blocks in the same array if you want rich text sections alongside your custom components:

of: [
  {type: 'block'}, // Rich text paragraphs with formatting
  {type: 'fullWidthImage'},
  {type: 'textWithImageLeft'},
  // ... other custom objects
]

This gives content editors the flexibility to mix formatted text with your custom section types.

Benefits of This Approach

Modular: Each section is independent and reusable
Flexible: Editors can add, remove, and reorder sections freely in the Studio
Type-safe: If using TypeScript, you get full type checking
Platform-agnostic: The structured data can be rendered anywhere (web, mobile, etc.)

This pattern is exactly what Sanity's Block Content system is designed for - treating your content like "Lego bricks" that can be assembled in different ways while maintaining structure and consistency. Each block in the array automatically gets a _key property for React's key prop, and the _type property tells you which component to render.

To add onto this, there will be three types of blog posts. Full page, right aligned, and left aligned. Each of these have their own set of unique components. I was wondering if there is any way to have an “if statement” in the schema, where if the “blog post type” is right aligned then only the right aligned objects are selectable

It doesn’t seem like my second message is possible based on the docs from here: https://www.sanity.io/docs/array-type

One more question to the bunch, do you think its best to just prefix everything? so for example:

document.posts

object.cta

, etc so that its easily distinguishable? IDK if prefixing a document is going to cause issues

If you had, say, a radio, and used fieldsets that corresponded, and used the "hidden" property, the documentation mentions that property, and "readOnly", as featured it shares with objects themselves, but also intimates that the behavior would be the same as well.
Since the behavior for an object field isn't just true/false but has a callback function that can carry the document itself as a prop, you might be able to use it to refer to a sibling field (the radio itself), see what it's value is, and hide the entire set that way.

Hmm I see what you mean, let me give that a shot!

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 free Explore the demo