De tres renderers a uno: cómo extraer un núcleo de render compartido

Hay una deuda técnica que no aparece como bug: el mismo bloque de código funciona en varios sitios, pero empieza a evolucionar distinto en cada uno. En mi caso era el renderer de Markdown enriquecido de mi plataforma.

Vista rápida

El estado de partida

Cuando hice la auditoría, encontré tres copias funcionales del mismo renderer en distintos consumidores: el editor canónico, una extracción parcial pensada para vistas internas y un reader vendorizado pensado para web.

Las tres usaban el mismo stack base: parser, sanitizador, resaltado de código, fórmulas y diagramas. El problema no era que hubiese tres archivos parecidos. El problema era que el lector veía tres versiones de lo que debería ser el mismo documento.

La señal visual

La señal más clara fue hacer una lista de bloques soportados. Si una tabla, una alerta o un diagrama renderiza distinto según el producto, el contrato ya está roto.

La tabla cambió la conversación: ya no era un refactor abstracto, era una promesa de lectura que debía ser consistente.

Criterio para extraer

Uso tres preguntas antes de sacar código a un paquete:

Si una de esas respuestas hubiese sido no, habría esperado. Como las tres eran sí, la extracción ya no era estética: era mantenimiento preventivo.

Qué cambió al extraer

La extracción no consistió en diseñar un renderer nuevo. Consistió en mover el contrato existente al lugar correcto y limpiar las dependencias.

1. Dependencias inyectadas

Antes, las copias leían sus librerías de runtime desde el ámbito global del navegador. Eso encaja en el cliente, pero no en un export server-side.

const preview = new PreviewRenderer({
  element,
  dependencies: {
    parser,
    sanitizer,
    highlighter,
    diagramEngine,
    mathEngine
  }
});

El core no decide de dónde vienen las librerías. Cada consumidor las proporciona.

2. Render puro separado de decoración

El render tiene dos fases:

Separar esas fases permite probar el parser sin DOM completo y probar decoradores con fixtures pequeños.

3. Tema como datos

La configuración de los diagramas dejó de depender de sincronizar CSS con scripts. El core acepta tokens de tema y el producto decide la estética.

La migración no destructiva

No migré todo a la vez. El orden importa porque cada consumidor tiene un riesgo distinto.

Qué valida que la decisión fue correcta

La extracción merece la pena cuando cambia la forma de operar:

La prueba más fuerte no es que el paquete exista. Es que un cuarto consumidor lo use sin pedir una excepción rara.

Lo que no haría

• No extraería por el segundo fork si el contrato todavía no está claro.
• No metería i18n, navegación, acciones de copiar o UI del editor dentro del core.
• No mezclaría esta migración con features nuevas del renderer.
• No usaría flags para convertir una librería en cinco productos escondidos.

La regla que me llevo

Una librería compartida no se diseña desde cero. Se descubre cuando el mismo contrato aparece en varios productos y empieza a doler en todos.

Este artículo es parte del trabajo de plataforma que cuento en Sobre mí. Si te interesa el tema, sigue el blog o escríbeme.