Diseñé Mal el Schema Durante Meses. Esto Es Lo Que Aprendí Sobre Sanity (a las Malas)
Enero de 2026. Llevaba semanas con un proyecto de contenido en Sanity que empezaba a crujir por las costuras.
El equipo editorial me mandaba mensajes tipo: “¿qué significa este campo?” o “¿esto es para móvil o escritorio?”. Y yo tenía que explicarlo cada vez.
El problema no era Sanity. El problema era yo, modelando el schema como si fuera un formulario de base de datos relacional de los de toda la vida.
Esto es lo que aprendí, sin rodeos.
El Error que Comete Todo el Mundo: Booleans Donde No Deberían Estar
Mira este campo típico que ves en casi cualquier proyecto:
Parece razonable, ¿verdad? Publicado o no publicado.
El problema es que el contenido no es binario en la vida real. Tienes borradores, revisiones, publicado, archivado, programado. Y cuando añades un segundo boolean isFeatured, y un tercero isArchived, ya tienes una combinación de estados inconsistentes que nadie del equipo entiende.
El patrón correcto es string literals:
Ahora el estado es explícito, extensible y autoexplicativo. Cuando en tres meses necesitas añadir scheduled, lo añades al array. Sin migraciones raras, sin ambigüedad.
Field Groups: El Schema que el Equipo Editorial Realmente Entiende
Cuando un documento tiene veinte campos, el editor se pierde. Los Field Groups agrupan campos por contexto, no por tipo técnico.
El redactor ve primero “Contenido”. El SEO manager va a su pestaña. El desarrollador configura en “Configuración”. Cada uno en su contexto. Los mensajes de “no encuentro el campo” desaparecen casi por completo.
Custom Previews: La Feature que Nadie Configura (y Que Salva Horas)
Por defecto, el Studio muestra el primer campo de texto como título del documento en el listado. Con documentos complejos, eso da listas inútiles tipo “undefined” o “Sin título”.
Ahora el listado de documentos en el Studio muestra el estado con emoji, el título y la imagen de portada. El equipo editorial sabe de un vistazo qué está pendiente de revisión sin abrir cada documento.
Reglas de Validación: Proteger al Equipo de Sí Mismo
Esto es brutal, en el buen sentido. Sanity permite validaciones síncronas y asíncronas directamente en el schema.
La diferencia entre .error() y .warning() es clave: los errores bloquean la publicación, las advertencias informan sin bloquear. Así puedes guiar sin frustrar.
Para campos más complejos, las validaciones asíncronas permiten incluso hacer llamadas externas, aunque yo las reservo para casos muy concretos donde el coste de la petición se justifica.
GROQ y el Schema: La Conexión que la Gente Ignora
Lo que defines en el schema determina cómo escribes tus queries GROQ. Cuando usas string literals en lugar de booleans múltiples, tus queries se vuelven más limpias:
coalesce() es una de las funciones de GROQ que más uso: devuelve el primer valor no nulo. En este caso, usa el excerpt manual si existe; si no, extrae los primeros caracteres del cuerpo automáticamente.
La función score() (o el operador _score con match) es la forma nativa de Sanity para búsqueda con relevancia. Sin servicios externos, sin configuración adicional.
El Pipeline de Imágenes: Lo Que Eliminó una Factura Mensual Importante
Antes de entender bien Sanity, usaba un servicio externo de optimización de imágenes. El problema era que pagaba por transformaciones que Sanity ya incluye en su pipeline nativo.
Sanity almacena metadatos de hotspot y crop directamente en el asset:
Con @sanity/image-url construyes URLs optimizadas al vuelo:
El campo lqip (Low Quality Image Placeholder) viene incluido en los metadatos del asset. Blur placeholder nativo sin configuración adicional.
Real-Time Previews: El Puente que Elimina el Tira y Afloja con el Equipo Editorial
Esto resolvió una dinámica repetitiva: el redactor publicaba, veía cómo quedaba en producción, pedía cambios, yo los hacía, vuelta a empezar.
Con useLiveQuery de next-sanity y Draft Mode de Next.js, el Studio muestra los cambios en tiempo real en el site antes de publicar:
El redactor ve los cambios mientras escribe. Sin deploys, sin capturas de pantalla, sin slack con adjuntos. Brutal.
Lo Que Cambia Cuando Diseñas el Schema Bien
Sanity tiene un tier gratuito generoso (20 seats, 500K peticiones API al mes) que cubre la mayoría de proyectos pequeños y medianos. Pero el valor real no está en el precio — está en el tiempo que ahorras cuando el schema está bien diseñado desde el principio.
Las decisiones de schema son las decisiones más baratas que tomas en un proyecto de contenido. Cambiarlas después es caro. Cambiarlas cuando hay treinta mil documentos indexados es muy caro.
Estos son los pasos concretos si quieres aplicar esto esta semana:
- Audita tus booleans. Si tienes más de dos booleans de estado en un documento, consolídalos en un string literal con opciones explícitas.
- Activa Field Groups en cualquier documento con más de ocho campos. Agrupa por audiencia (editorial, SEO, técnico), no por tipo de dato.
- Añade custom preview a todos tus tipos principales. Incluye el estado con un indicador visual.
- Valida los campos SEO con rangos de caracteres. Bloquea publicación si meta description está vacía.
- Activa hotspot en todas tus imágenes y verifica que usas
lqippara blur placeholders.
Seguimos construyendo.
