Construir un editor Markdown funcional implica más que guardar datos: necesitas reflejar todo en pantalla. Aquí avanzamos en la manipulación del DOM con JavaScript para mostrar notas, editor y preview, apoyándonos en buenas prácticas de Git, documentación con JSDoc y herramientas de inteligencia artificial como Copilot.
¿Cómo documentar un pull request profesional en GitHub?
Antes de tocar el DOM, conviene revisar cómo se comunica un cambio en un equipo real. Un pull request bien hecho cuenta una historia: qué cambió, por qué cambió y a quién impacta.
En el proyecto se incorporó un nuevo feature de persistencia de notas usando local storage, y la descripción del PR sigue una plantilla con estos bloques [01:05]:
- Breve descripción del cambio.
- Cambios efectuados en el código.
- Motivación detrás de la mejora.
- Impacto esperado.
- Notas generales de implementación.
Esta plantilla puedes encontrarla en internet o pedirla a una herramienta como ChatGPT a partir de tu código. Además, asignas un reviewer (en este caso Felipe), te marcas como assignee y agregas labels tipo enhancement.
¿Qué es un pull request? Es una solicitud para integrar cambios de una rama a otra en GitHub, donde otros revisan tu código, dejan comentarios y aprueban antes de fusionarlo.
GitHub te permite ver los cambios línea por línea, así que aunque una función no se mueva, sí notarás que ahora tiene su documentación apropiada [02:20].
¿Cómo mostrar y ocultar el editor y el preview con JavaScript?
Con la persistencia lista, toca llevar las notas a la interfaz. Lo primero es declarar una variable global en la parte superior del archivo: let currentNoteId = null;. Esta variable rastrea cuál nota está activa y la usaremos en varias funciones [03:25].
Luego creas dos funciones simples para alternar visibilidad. La idea es seleccionar las secciones del editor y el preview con document.querySelector y cambiar su propiedad style.display.
javascript
/**
- Muestra el editor y el preview
*/
function showEditorAndPreview() {
const editorSection = document.querySelector('.editor-section');
const previewSection = document.querySelector('.preview-section');
editorSection.style.display = 'flex';
previewSection.style.display = 'flex';
}
/**
- Oculta el editor y el preview
*/
function hideEditorAndPreview() {
const editorSection = document.querySelector('.editor-section');
const previewSection = document.querySelector('.preview-section');
editorSection.style.display = 'none';
previewSection.style.display = 'none';
}
Un detalle: cuidado al copiar y pegar. El autocompletado del editor a veces sugiere propiedades equivocadas, así que verifica siempre que estés usando style.display y no otra cosa [05:10].
¿Cómo usar JSDoc e IA para renderizar listas de notas?
La siguiente tarea es renderizar la lista de notas, el editor y el preview. Aquí entra JSDoc, un estándar para documentar funciones en JavaScript que describe parámetros, tipos y propósito.
¿Por qué documentar antes de programar?
Escribir la documentación primero te obliga a definir el contrato de la función: qué recibe, qué devuelve y qué hace. Para renderNoteList queda así [06:40]:
javascript
/**
- Renderiza la lista de notas en el DOM
- @param {Array} notes - Array de notas a renderizar
*/
Para el editor y el preview el patrón se repite, indicando que el editor recibe un object o null (nota a renderizar o editor vacío) y el preview recibe un string con el contenido Markdown.
¿Qué es JSDoc? Es una sintaxis de comentarios que describe funciones JavaScript con etiquetas como @param y @returns, para que tu equipo y tu editor entiendan el código sin ejecutarlo.
¿Cómo escribir un buen prompt para Copilot o Cursor?
Manipular el DOM puede ser repetitivo, así que apoyarte en herramientas como Copilot, Cursor, Windsurf o ChatGPT acelera el trabajo. La clave está en darles contexto y tareas claras [08:15].
El prompt usado para generar renderNoteList se construye como una lista de subtareas en lenguaje natural, casi como pseudocódigo:
- Crea una función
renderNoteList que reciba una lista de notas.
- Limpia el contenedor
noteList antes de renderizar.
- Si la lista está vacía, muestra un mensaje de estado vacío.
- Si hay notas, renderiza cada una con título, extracto y fecha.
- Marca la nota activa comparando su ID con
currentNoteId usando solo DOM nativo.
Una regla práctica: no pases más de cinco tareas en un solo prompt. Más allá de eso, la herramienta empieza a alucinar y entrega código que no cumple el objetivo. Tareas pequeñas, contexto claro y selección del fragmento relevante hacen la diferencia.
¿Cuántas tareas debo dar a una IA en un prompt? Máximo cinco subtareas concretas. Pasado ese límite, los modelos pierden precisión y empiezan a inventar lógica que no pediste.
Una vez que la IA genera el código, no lo aceptes a ciegas. Léelo, pruébalo y verifica que cumple el objetivo. Esa revisión final es lo que separa un copia y pega arriesgado de un uso profesional de la herramienta.
¿Qué herramienta usaste tú para resolver el render del editor y el preview: Cursor, Windsurf, Copilot o ChatGPT? Cuéntame en los comentarios cómo te fue con tus prompts.
