El error invisible que rompe tu Markdown en el frontend 🤯
La mayoría de los desarrolladores ignoran este problema hasta que el HTML final se convierte en un caos. El problema es simple pero frustrante: la indentación. Cuando escribimos Markdown dentro de componentes, solemos
Artículo
Una lectura sobre tecnología y sistemas digitales, escrita para ir al punto y dejar claras las ideas principales.
Tema principal
desarrollo frontend
Fuente
dev.to
Puntos clave
- La mayoría de los desarrolladores ignoran este problema hasta que el HTML final se convierte en un caos.
- El problema es simple pero frustrante: la indentación.
- Cuando escribimos Markdown dentro de componentes, solemos indentar el contenido para que el código sea legible. Sin embargo, la mayoría de las librerías interpretan esos espacios como bloques de código, envolviendo todo
- El resultado es una elección imposible: o tienes un código limpio en tu editor, o tienes un renderizado correcto en el navegador. No puedes tener ambos.
Bloque 1
La mayoría de los desarrolladores ignoran este problema hasta que el HTML final se convierte en un caos.
El problema es simple pero frustrante: la indentación.
Bloque 2
Cuando escribimos Markdown dentro de componentes, solemos indentar el contenido para que el código sea legible. Sin embargo, la mayoría de las librerías interpretan esos espacios como bloques de código, envolviendo todo en etiquetas y sin que lo queramos.
El resultado es una elección imposible: o tienes un código limpio en tu editor, o tienes un renderizado correcto en el navegador. No puedes tener ambos.
Bloque 3
La clave está en abstraer la limpieza del whitespace en una utilidad agnóstica al framework.
Aquí los puntos técnicos clave para resolverlo:
Bloque 4
• Normalización de espacios: Eliminar la indentación basada en pestañas o espacios antes del procesamiento del Markdown. • Agnosticismo de Framework: Implementar la lógica en una utilidad pura de JS para que funcione igual en Astro, React, Vue o Svelte. • Control de salida: Permitir un modo 'inline' para omitir etiquetas de párrafo cuando el contexto lo requiera. • Mejora de DX: Priorizar la legibilidad del código fuente sin sacrificar la integridad del DOM.
Al final, la verdadera arquitectura de software no se trata solo de escalar sistemas, sino de optimizar la experiencia del desarrollador (DX) eliminando fricciones repetitivas.
Bloque 5
¿Cómo manejan ustedes el renderizado de Markdown en frameworks modernos para no sacrificar la legibilidad del código?