Al comparar dos versiones de una propuesta, ya hay bastante que recordar. Si cambio de versión y la página también cambia el paquete que había elegido, termino comparando dos cosas a la vez.
Ese detalle fue uno de los criterios al ordenar un pequeño ejemplo en HTML y JavaScript: dos paquetes, dos revisiones y un resumen con precio, plazo y entregables. Los importes son ficticios.
Dos decisiones, no cuatro botones independientes
La selección cabe en dos variables:
let revision = "first";
let plan = "essential";
Cambiar la revisión modifica únicamente revision. Cambiar el paquete modifica únicamente plan. No hay una razón para reiniciar la otra elección.
Un ejemplo mínimo de los datos sería este. Los importes están expresados en USD, solo para ilustrar la estructura:
const proposals = {
first: {
essential: { price: 4800, weeks: 3 },
complete: { price: 7200, weeks: 4 }
},
revised: {
essential: { price: 5400, weeks: 4 },
complete: { price: 8100, weeks: 5 }
}
};
function currentProposal() {
return proposals[revision][plan];
}
El resultado se deriva de la selección. Guardar también el precio como estado crearía otra cosa que mantener sincronizada.
Un solo sitio para actualizar la interfaz
La tentación es poner un poco de lógica en cada botón: este cambia el precio, aquel cambia el plazo, otro reconstruye la lista. Cuesta ver si todos terminan dejando la página en el mismo estado.
La alternativa del ejemplo es que cada evento actualice una variable y llame a render(). Esa función obtiene el registro de la combinación actual y actualiza el resumen, los entregables y aria-pressed de los botones.
Para los textos se usa textContent. Un entregable es texto; no hace falta interpretarlo como HTML.
Hay una consecuencia útil: si estoy viendo el paquete completo y paso a la revisión, sigo viendo el paquete completo. El precio puede cambiar porque cambió el alcance, pero mi selección permanece.
Una tabla correcta no garantiza una transición correcta
Estos son los cuatro resultados esperados:
| Revisión | Paquete | Precio ficticio (USD) | Plazo |
|---|---|---|---|
| Inicial | Básico | 4800 | 3 semanas |
| Inicial | Completo | 7200 | 4 semanas |
| Revisada | Básico | 5400 | 4 semanas |
| Revisada | Completo | 8100 | 5 semanas |
Comprobar cada fila sirve para revisar los datos. Después conviene recorrer una secuencia:
Completo → Revisada → Básico → Inicial.
En cada paso, hay que comparar el precio, el plazo, los entregables y el estado seleccionado de ambos grupos. Así también se busca contenido que se haya quedado de la selección anterior.
Los controles son botones nativos. Se puede recorrer la interfaz con Tab y activarlos con Enter o Espacio. aria-pressed comunica la selección y una región aria-live="polite" anuncia el resumen. Eso no sustituye una prueba con lectores de pantalla.
El nombre del botón también forma parte del comportamiento
Las dos revisiones ya están en el archivo. El selector las muestra: no guarda cambios ni publica una actualización.
Llamarlo “vista previa de la revisión” ayuda a entender esa diferencia. Para modificar una página alojada, todavía hay que subir el archivo cambiado y comprobar el enlace público.
Es un detalle pequeño, pero el control no debería prometer una acción que no ha ocurrido.
La versión en inglés con el HTML y JavaScript completos incluye el ejemplo reproducible. Esta versión se centra en el criterio de conservar las elecciones durante la comparación.
¿En qué casos sí tendría sentido reiniciar el paquete al cambiar de versión? Por ejemplo, si un paquete deja de existir, haría falta explicar ese cambio en lugar de aplicarlo en silencio.
Top comments (0)