Arena de Código

Examen de HTML, CSS y JavaScript para el salón, en formato tipo CodeWars: 75 retos (25 de HTML, 25 de CSS y 25 de JavaScript), de lo más fácil a lo más difícil, sacados de las guías 1, 2 y 3 que están en guias/.

La idea de fondo es una sola: se escribe, no se pega. Los alumnos pueden preguntarle a quien quieran —a un compañero o a una inteligencia artificial— pero la pregunta y la respuesta las teclean ellos. Eso es lo que se queda.

---

Arrancar

npm install
npm run dev

Y abrir http://localhost:3000.

Así de simple funciona ya: el progreso se guarda en el navegador de cada alumno. Para que además sobreviva a cambiar de computador y para tener panel de profesor, hay que conectar Supabase (ver abajo).

Las pantallas

Ruta	Para qué
/	El alumno escribe su nombre y entra. Ese nombre es su llave.
/examen	El examen. Enunciado, terminal y resultado.
/proyecto	Índice de los proyectos guiados, con el avance de cada uno.
/proyecto/p1 … /proyecto/p8	El taller: código del modelo, terminal del alumno y misiones.
/profesor	Panel del profesor. Pide la clave de PROFESOR_CLAVE.
/juegos	Los cinco juegos de recreo: triqui, parejas, invasores, buscaminas y tetris.
/verificar	Autodiagnóstico: corre las 75 soluciones de referencia contra sus propias pruebas.
/verificar-proyecto	Autodiagnóstico de los proyectos guiados: resuelve sus 58 misiones y las revisa.

Las dos pantallas de /verificar valen la pena cada vez que se toque una pregunta o una misión: si algo sale en rojo, eso quedó imposible de resolver o su prueba no mide lo que dice.

Los proyectos guiados

Es lo más parecido a CodePen que hay aquí, con una diferencia: el código del modelo no se puede seleccionar ni copiar. A la izquierda el alumno ve el proyecto terminado —alrededor de 20 líneas de HTML, de CSS y de JavaScript— y abajo el resultado funcionando, con sus botones y todo. A la derecha tiene su propia terminal, la misma del examen, que rechaza cualquier pegado. La única forma de avanzar es teclearlo.

Cuando lo replica, empiezan las misiones, y ahí es donde se aprende: son cambios pequeños que solo salen si entendió qué línea hace qué.

#	Proyecto	Qué enseña	Misiones
1	La tarjeta que saluda	Etiquetas, colores, centrar con margin: auto, un contador de clics	6
2	La lista de tareas	Leer un input, crear elementos con JavaScript, flexbox, singular/plural, la tecla Enter	7
3	La calculadora de la cuenta	Number(), un select, validar con if, classList, Math.round, calcular mientras se escribe	7
4	El quiz	Un arreglo de objetos, forEach, un índice que avanza, hidden, porcentajes, arreglar un botón que rompe el juego	8
5	La tiendita con carrito	Estado en un arreglo, plantillas con ${}, data-* y delegación, map/find/filter/reduce, toLocaleString, un cupón	8
6	El cronómetro	setInterval y clearInterval, padStart, disabled, prepend, un atajo con document.addEventListener, classList.toggle	7
7	Tres en raya	El tablero como arreglo, líneas ganadoras con find/every/includes, desestructurar, marcador, deshacer con un historial, una pista	7
8	El juego de memoria	Barajar, un estado que se vigila (primera, bloqueado), setTimeout, un reloj que arranca y para, nueva partida, récord y niveles	8

Cada misión se revisa ejecutando el proyecto del alumno de verdad: se monta en la ventanita, se usa como lo usaría una persona —escribir en el cuadro, dar clics, presionar Enter— y después se mide el resultado: texto, estilo calculado, cuántos elementos hay, qué quedó escrito en un input, si lleva una clase, si la caja está centrada.

Los temporizadores tienen truco. En la vista previa son de verdad y el cronómetro corre; en la revisión son de mentira, y la acción esperar adelanta el reloj de golpe, disparando en orden los setTimeout y setInterval que tocaban. Así “esperar un minuto” tarda un instante y da siempre el mismo resultado. Como la ventanita se reutiliza entre corridas, al montar un proyecto se barren los temporizadores y los listeners de document y window que dejó el anterior.

Esa revisión corre en la misma ventana donde el alumno ve su resultado, y no en un iframe escondido: Chrome no le da maquetación a un iframe invisible o fuera de la pantalla, y ahí toda medida da cero. De paso, el alumno ve los clics que le dio la revisión.

Los proyectos y sus misiones viven en src/lib/proyectos.ts; agregar uno nuevo es agregar otro objeto a ese archivo (la ruta /proyecto/<id> y el índice se arman solos). Cada misión guarda además el cambio exacto que la resuelve (parches), y eso es lo que le permite a /verificar-proyecto comprobar que todas se pueden pasar.

Cómo se califica

No se compara texto contra texto: el código del alumno se ejecuta de verdad dentro de un iframe aislado (public/runner.html, con sandbox="allow-scripts" y sin allow-same-origin, o sea en un origen opaco que no ve ni cookies ni la app), y sobre el resultado se corren pruebas declarativas.

Eso significa que cualquier solución válida pasa, no solo la que se nos ocurrió a nosotros. Los tipos de prueba están en src/lib/types.ts:

This is the beginning of the README. Read the rest at the original. Read the full README ↗