Avoiding attribute cap with conditional styling customization documents

Happy New Year! Your concern about hitting the attribute cap is valid, but I have good news: your proposed solution is likely more complex than necessary for this use case.

First, let me address the attribute limit concern. Sanity documents do have attribute limits, but these limits are quite generous for most use cases. A spacing object with margin and padding properties on each of your 15-20 layouts shouldn't come close to hitting the cap, even if you expand to include additional styling properties.

The attribute limit applies to the total number of unique keys across your entire document structure. Having nested objects (like your spacing object) is actually a good pattern because:

• Nested fields count efficiently toward the limit
• It keeps your schema organized
• It's easier to manage and understand

My recommendation: Keep it simple and stick with your current approach of adding styling objects directly to each layout. Here's why:

1. Nested objects are the standard pattern - Having a spacing object (and potentially colors, typography, etc.) directly on your layout schemas is exactly how most Sanity projects handle this
2. Conditional fields - You can use hidden conditionals to only show these styling fields when needed, keeping the UI clean
3. Fieldsets - Group your customization fields in collapsible fieldsets so they don't clutter the interface

Here's a cleaner approach than creating separate documents:

{
  name: 'heroLayout',
  type: 'object',
  fields: [
    // Your regular layout fields
    {
      name: 'enableCustomStyling',
      type: 'boolean',
      title: 'Enable Custom Styling',
      initialValue: false
    },
    {
      name: 'customStyles',
      type: 'object',
      title: 'Custom Styles',
      hidden: ({parent}) => !parent?.enableCustomStyling,
      fieldsets: [
        {name: 'spacing', title: 'Spacing', options: {collapsible: true}},
        {name: 'colors', title: 'Colors', options: {collapsible: true}},
      ],
      fields: [
        {
          name: 'marginTop',
          type: 'string',
          fieldset: 'spacing'
        },
        // etc.
      ]
    }
  ]
}

When would your separate document approach make sense?

• If you're hitting actual attribute limits (you'll get clear errors when trying to save)
• If you need to reuse the same customization across multiple layouts
• If you need to version or audit customization changes separately

For your use case where customizations are layout-specific and used only 10% of the time, keeping them as nested objects is simpler, more performant (fewer document lookups), and easier to maintain. The attribute cap shouldn't be a concern unless you're dealing with hundreds of fields per document.