El bug silencioso que rompe tus page builders en Sanity 🤯
Seguro te ha pasado: añades una sección nueva a tu CMS, todo parece correcto, pero en producción la sección es un agujero blanco. No hay error en la consola, no hay pantalla roja. Simplemente, no está. Este es el "impue
Artículo
Una lectura sobre tecnología y sistemas digitales, escrita para ir al punto y dejar claras las ideas principales.
Tema principal
arquitectura de software
Fuente
dev.to
Puntos clave
- Seguro te ha pasado: añades una sección nueva a tu CMS, todo parece correcto, pero en producción la sección es un agujero blanco. No hay error en la consola, no hay pantalla roja. Simplemente, no está.
- Este es el "impuesto de la sección". El problema es que para añadir un componente, un ingeniero debe tocar 5 puntos distintos:
- 1. El Schema en el Studio
- 2. La proyección de la query GROQ
Bloque 1
Seguro te ha pasado: añades una sección nueva a tu CMS, todo parece correcto, pero en producción la sección es un agujero blanco. No hay error en la consola, no hay pantalla roja. Simplemente, no está.
Este es el "impuesto de la sección". El problema es que para añadir un componente, un ingeniero debe tocar 5 puntos distintos:
Bloque 2
1. El Schema en el Studio 2. La proyección de la query GROQ 3. El componente React 4. El mapa del renderizador 5. Los tipos de TypeScript
Como somos humanos, olvidamos uno. El resultado es un fallo silencioso que llega al cliente.
Bloque 3
El insight clave es simple: el 80% de esto es fontanería genérica que repetimos en cada proyecto. La solución es dejar de escribir código manual y pasar a un modelo de co-localización.
Así es como se soluciona a nivel de arquitectura:
Bloque 4
• Co-localización: Define el tipo, la query y el render en un único objeto de configuración. Si existe el componente, existe la query. • Generación automática: Deriva la proyección GROQ dinámicamente desde la lista de secciones, eliminando el riesgo de olvidar un campo. • Tipado estricto: Usa tipos mapeados para que el compilador marque error en el build si falta un renderizador para un tipo de bloque. • Tests de integridad: Un test simple en CI que compare el mapa de renderizadores contra los tipos registrados en el CMS.
Deja de luchar contra el drift de configuración. Extrae la infraestructura, mantén tus componentes y haz que el sistema falle fuerte y rápido en el desarrollo, no en silencio en producción.
Bloque 5
¿Ustedes cómo están resolviendo la sincronización entre el esquema del CMS y el renderizado en el frontend para evitar estos fallos?