Hasta ahora, nuestro juego ha sido contenido dentro de este único componente wordleboard.
Ha estado funcionando muy bien, pero desde que nuestra aplicación empezó a crecer,
este componente creció con ella.
Este componente es actualmente responsable de dos cosas,
mostrar la información y recoger la información del usuario.
Este puede ser un buen momento para
para extraer una de estas preocupaciones en un componente dedicado.
Observa que no empezamos este proyecto
predeterminando
que componentes vue nuestra aplicación va a necesitar.
En su lugar, hemos optado por esperar a estos componentes
aparezcan de forma natural a medida que evolucione la aplicación.
Bien, vamos a mover todo lo relacionado con la recogida de datos del usuario
en un componente dedicado a la entrada de conjeturas.
Dado que la mayor parte de esta lógica aquí
va a estar relacionada con la recopilación de la entrada de conjeturas,
Creo que deberíamos ser capaces de duplicar este tablero de palabras
en un componente de entrada de conjeturas
y luego eliminar cualquier cosa que esté relacionado con la representación de la conjetura.
Así que esta parte de aquí no pertenece a la entrada guess.
Tampoco necesitamos recibir la palabra del día.
Y no necesitamos llevar la cuenta de las conjeturas presentadas.
Lo que vamos a hacer es comunicarnos con el padre
cada vez que el usuario realmente envía una conjetura.
La forma más común en que un componente hijo se comunica con un padre
es a través de la emisión de eventos.
Para emitir un evento en este componente, podemos hacer uso de defineEmit.
Y vamos a definir que emita un evento llamado guess-submitted
que contiene una cadena como la carga útil
que va a representar la conjetura que el usuario está enviando.
Podemos hacerlo así
A través de esto, estamos determinando que nuestro componente
emite un evento guess-submitted
que tiene una carga útil que contiene sólo un elemento de adivinar
que es de tipo cadena.
Muy bonito, ¿verdad?
Definiendo emits así,
estamos aprovechando TypeScript para darnos un buen intellisense.
Mira esto.
Si intento emitir un evento que no ha sido definido, por ejemplo, foobar,
se puede ver que estoy recibiendo un error de tipo, porque foobar,
no es un evento que he determinado.
Y si proporciono el evento correcto con una carga no válida,
También obtengo un error porque el payload debe ser de tipo string.
Esta es una manera muy simple pero eficaz de hacer nuestro código base más robusto.
Bien, parece que estamos bien en el componente guessInput.
Ahora vamos a hacer uso de ella en el worldeboard.
Ya no necesitamos este método onSubmit.
Ya no necesitamos el método formattedGuessInProgress,
ni el guessInProgress,
y podemos eliminar las importaciones no utilizadas.
Muy bien, vamos a ejecutar nuestras pruebas.
Y estamos pasando.
Genial, creo que estamos en un buen punto para hacer un commit.
Extraer GuessInput en un componente dedicado.
Ahora podría ser un buen momento
para poner un poco de estilo a nuestro componente.
Siéntase libre de hacer esto de la forma que prefieras.
Lo haré por aquí y luego te mostraré lo que tengo.
Esto es lo que tengo hasta ahora.
Dado que el estilo no es el objetivo de la lección,
Voy a explicar brevemente lo que he hecho.
Pero si quieres discutir más sobre esto,
no dude en en ponerte en contacto conmigo en Twitter.
Para el estilo, decidí que quería para ocultar el tipo de entrada nativa elemento de texto
y en su lugar hacer una conjetura con formato como una lista de letras.
Pero antes de empezar a estilizar nada
Quería asegurarme de que nuestra entrada de entrada estuviera siempre enfocado.
Esta prueba de aquí es como lo he hecho.
Y maneja un par de conceptos avanzados de vue test utils,
pero te daré una breve explicación.
Una forma de evaluar si un elemento está enfocado
es comprobando el elemento activo del documento.
Sin embargo, tus pruebas no funcionarán para el elemento activo
si no defines explícitamente un attachTo.
Déjame demostrártelo.
Si ejecuto esta prueba de aquí, puedes ver que está pasando,
pero si quito el attachTo de las opciones de montaje,
la prueba ahora falla.
Y la razón del fallo es que el elemento activo es el cuerpo,
no la entrada.
Por eso es necesario el attachTo.
Y como puedes ver aquí, Estoy tratando de difuminar lejos de la entrada,
pero la entrada debe permanecer siendo el elemento activo.
También quiero que la entrada esté autoenfocada al principio.
Para pasar esta prueba,
He asignado el atributo de autoenfoque a la entrada,
y también he definido un manejador de eventos para el desenfoque
que el foco de nuevo en la entrada, para que el usuario no pueda perder el foco.
Para dar un poco de sabor,
También he creado esta propiedad llamada letra de datos,
que mantiene un registro de la letra
que el cuadrado de la letra está representando en ese momento.
La razón por la que quería hacer un seguimiento de la letra
es sólo que yo quería una animación pop cada vez que una letra
pasara de vacía a otra cosa.
Así que esto es lo que está pasando aquí.
Estoy buscando todos los elementos de la lista que no tienen una letra de datos
de un espacio vacío.
Y si eso ocurre entonces la animación pop se dispara.
Por último, una clave para llevar de este estilo de aquí
es esta palabra clave de alcance.
Me gusta usar esto por defecto en mis proyectos
porque fuerza todos los estilos definidos en este componente
sólo se apliquen a este componente.
Bueno, estos son los principales puntos clave que quería cubrir con respecto al estilo.
Pero si quieres profundizar en esto,
el enlace al repositorio está en la descripción.
Y de nuevo, no dudes en ponerte en contacto.
El worldeboard en sí también tenía un poco de aspecto renovado.
He añadido una pequeña animación para el pasaje de retroalimentación
aparezca en la pantalla,
y también centralicé los elementos del worldeboard.
Y aquí está una cosa realmente agradable de todo esto.
No tuve que alterar ninguna de nuestras pruebas existentes,
pero mira esto.
Todos están pasando.
Hicimos una renovación completa en el aspecto de la aplicación,
pero la funcionalidad básica permanece sin cambios.
Desde que escribimos nuestras pruebas
centrándonos en el comportamiento en lugar de la implementación,
nuestras pruebas siguen pasando.
Muy bonito, ¿verdad?
También quiero hacer hincapié en que hice mi restyling de la aplicación en pequeños trozos.
Hacía algo y luego ejecutaba las pruebas,
vería que todas pasaban, y entonces haría un commit.
Y a veces si el commit estaba relacionado con el estilo,
Me limitaría a modificar con el anterior anterior de ese componente.
Haznos la vida más fácil.
Confirmar a menudo. Prueba a menudo.
Estupendo. Juntos, hemos visto de primera mano los beneficios de escribir tests flexibles.
Esfuérzate siempre por escribir tests
que no estén atadas a detalles de implementación,
sino al comportamiento y la funcionalidad.
Escribir pruebas que estén estrechamente a la implementación
resultará en un interruptor de prueba frágil,
que tiene una mayor probabilidad de dar falsos negativos,
es decir pruebas que fallan cuando no deberían.
Si ves que tus pruebas demasiado en las propiedades internas
y atributos de un componente,
podría ser una señal de que tu prueba debería ser refactorizada.
Centrarse en el comportamiento conduce a un interruptor de prueba que es robusto,
y no frágil,
que acoja y facilitará futuros cambios
y refactorizaciones a su código base, en lugar de crear desgaste.