Saltar a contenido

ADR-0001 · Los bloques comerciales no tienen componente React en este repo

  • Estado: aceptado
  • Decisores: no registrado en el repositorio (autoría del código: hquintero1)
  • Fecha de la decisión: no registrada. La implementación aparece en el commit 1dcdc7a ("agregados nuevos bloks y colecciones: slides, navegacion principal, product-grid") y queda explícita en fea2e5f (2025-12-03), que agrega el comentario correspondiente en RenderBlocks.tsx.

Contexto y problema

El repositorio nació como fork del website template oficial de Payload, que trae un sitio Next.js completo: cada bloque de contenido tiene su config de Payload y su componente React, y RenderBlocks.tsx los mapea. Pero la plataforma ya tiene un storefront de e-commerce propio, con su propio diseño, routing y build. Los bloques comerciales que se agregaron después (hero, heroSlider, productGrid) están pensados para las páginas de ese storefront, no para el sitio que viene con el template.

Mantener una implementación React por bloque en los dos lados significaba duplicar el diseño y arriesgar que las dos versiones divergieran.

Opciones consideradas

  1. Bloques solo como config + tipos; el storefront los renderiza (elegida)
  2. Implementar el componente React también acá, para que el sitio del template quede completo
  3. Descartar el sitio (frontend) del template por entero y dejar solo el admin y la API

Decisión

Los bloques comerciales se definen solo como configuración de Payload (más interfaceName para que el storefront tenga el tipo) y no se registran en RenderBlocks.tsx. Las entradas quedan comentadas ahí, con una nota que dice por qué:

// Bloques sin componente frontend (se renderizan en el storefront externo)
// hero: null,
// heroSlider: null,
// productGrid: null,

Es el mínimo necesario: el CMS tiene una sola responsabilidad —modelar y servir el contenido— y el diseño vive donde se consume. No se borró el sitio (frontend) del template porque sigue siendo lo que hace funcionar el live preview de páginas y posts para los editores.

Consecuencias

Positivas

  • Una sola implementación visual de cada bloque, en el storefront.
  • Agregar un bloque es agregar config + tipos: sin trabajo de frontend en este repo.
  • El contrato con el storefront es la API, no el HTML.

Negativas / deuda asumida

  • El sitio (frontend) de este repo muestra páginas incompletas: los bloques comerciales simplemente no se dibujan. Quien lo abra sin conocer esta decisión lo lee como un bug, y va a "arreglarlo".
  • El repo conserva código del template que casi no se usa, con el costo de mantenimiento y la confusión que eso implica (por ejemplo, los dos conceptos distintos de "hero" que conviven).
  • Un cambio de forma en un bloque exige coordinación con el repo del storefront: no hay nada en este repo que detecte la ruptura.