Crea una cuenta y continúa aprendiendo 🚀

Regístrate o inicia sesión para continuar aprendiendo:

Frontend Aprendiz

ESLint

Antes de empezar a refactorizar veamos qué es ESLint, y cómo podemos usar esta herramienta para identificar errores en tiempo de compilación.

Esta lección no cuenta con recursos adicionales.

Si crees que hace falta algo, o necesitas ayuda, puedes publicar una pregunta en el foro.

En este módulo nos vamos a encargar de actualizar nuestro carrito de compras de tal manera que muestre información del producto, no solamente su idea. Para esto vamos a tener que refactorizar nuestro código. Refactorizar significa cambiar cómo algo funciona en nuestro proyecto. O sea que podemos tener una característica implementada ya de una manera y vamos a cambiar la lógica para que funcione de otra forma. En nuestro caso nuestro carrito de compras presenta detalles donde cada detalle es un CartDetail. Si nosotros hacemos control clic, vemos que un CartDetail se define como un productId y una cantidad. Lo que vamos a hacer es reemplazar este productId por un objeto product. De tal manera que cuando se agregue un producto se guarde la información completa del producto, no solamente el ID. Y si hacemos ello vamos a poder luego mostrar esta información cuando pintemos los detalles. Sin embargo antes de hacer cambios es importante conocer que nuestro proyecto cuenta con una herramienta llamada ESLint. Esta herramienta ya está incluida en nuestro proyecto y por lo tanto podemos usarla ejecutando el comando npm run lint. Pero que es ESLint? Esta herramienta como bien lo indica su página oficial eslint.org. Nos ayuda a encontrar y corregir problemas en nuestro código JavaScript. En general un linter o una herramienta de linting nos permite realizar un análisis estático sobre nuestro código para encontrar problemas. Es decir sin la necesidad de ejecutar nuestro proyecto, la herramienta va a analizar nuestro código tal como está y nos va a dar su carencias de cosas que podemos mejorar o corregir en caso que se identifiquen errores. Si, entonces vamos a ejecutar el comando npm run lint por primera vez en nuestro proyecto. Y bien, aquí nos muestra cuatro errores y tres warnings en total siete problemas nos dicen. Revisemos cada uno de ellos, el primer problema es un warning que se encontró en el archivo de App.vue. App.vue es nuestro componente principal, lo vamos a abrir, dentro de App.vue nos dice que RouterView se encuentra definido pero nunca es usado. Bien aquí estamos importando RouterView y a pesar que funciona estando aquí en el template, lo correcto en sí para una declaración local es además de importar declarar que queríamos usar este componente en el objeto de components. De seguro que en este caso funciona porque nuestro RouterView está declarado de manera global. Veamos qué ocurre si eliminamos ambos. Incluso si eliminamos ambos nuestro proyecto sigue funcionando, eso es porque nuestro RouterView se encuentra declarado de manera global en nuestro proyecto Eso se encuentra aquí en nuestro archivo main.ts En caso de que tú tengas inconvenientes con usar el componente RouterView, recuerda que siempre puedes importarlo de manera local con import y luego declarar que quieres usarlo en la sección de components. Por ahora, como funciona sin esto, yo voy a quitarlo. Voy a ejecutar nuevamente el comando npm run lint y de 7 hemos pasado a 6 problemas. Vayamos en orden y corrijamos los demás. En el caso del componente Cart ocurre algo bastante similar, dice que estamos importando RouterLink, pero que no lo estamos usando. Nosotros realmente sí lo estamos usando, solo que como ya lo tenemos definido nosotros de manera global no es necesario hacer este import. También nos dice que los elementos que iteran, por ejemplo un v-for, requieren de una key. Vamos a buscar aquí nuestro v-for y tenemos nuestro v-for. Este v-for está aplicado sobre cada list item. Y aquí hay un :value, en realidad usemos :key, ya que la directiva v-for se acompaña siempre de un v-bind:key, que se puede escribir de esta manera también. Y de esta manera nosotros indicamos qué valor hace único a cada iteración, en este caso el idea del producto. Vamos a ejecutar una vez más el comando npm run lint y de 6 errores que teníamos hemos pasado a 4. Ahora nos dice que el componente llamado cart debe ser siempre escrito como varias palabras, no solo una. Aquí nos recomienda cambiar el nombre del componente cart para indicar mejor qué representa. Si nos fijamos todos nuestros componentes en realidad tienen más de una palabra. Por ejemplo, nuestras vistas terminan en view. Estas vistas representan a cada página, es decir, cada ruta de nuestro proyecto. Tenemos HomeView, AboutView, CartView. Respecto a los demás componentes, tenemos productList, un listado de productos, productCart, una tarjeta que representa un producto, un cart. CategoryList, una lista de categorías. TopBar, la barra que va en la parte superior. Sin embargo, cart es muy general, entonces lo que nos recomienda es usar dos palabras como mínimo. En nuestro caso, el componente cart es una tarjeta, es un card. Por lo tanto, vamos a renombrarlo. En este caso, lo vamos a llamar CartCard. Es una tarjeta que representa el carrito de compras. O también podríamos llamarlo ShoppingCart, que es un carrito de compras, para que se diferencia de nuestro CartView, que es más general. Guardamos. Nosotros, vía SCode, podemos dar clic derecho y hacer clic en esta opción que dice Find File References, o sea encontrar referencias a este archivo. Si hacemos ello vemos desde donde se está usando este componente. Se está usando desde CardView. En CardView se importa ShoppingCart con el nombre de cart y se continúa usando con ese nombre. Esto seguro que funciona, pero es mejor si usamos un nombre que coincida con el archivo que estamos importando. Aquí tenemos un uso, el otro uso se encuentra desde productList. En productList nosotros teníamos debajo de listado de productos el carrito de compras, pero en algún punto lo eliminamos. Como lo eliminamos, en realidad aquí podemos eliminar el import y podemos eliminar también la declaración del listado de componentes. De hecho ya que estamos aquí en productList, vamos a eliminar este prop details, antes venía desde el componente padre, ya no hacemos más eso porque usamos nuestro store. Y vamos a eliminar también el type card detail, porque no está en uso. Hasta aquí guardamos, verificamos que nuestro proyecto sigue funcionando. El comando npm run lint, ahora nos muestra solo tres problemas, dos errores y un warning. El primer error nos dice que ocurre en CategoryList. En CategoryList, aquí nos dice que ocurrió un error de parsing, porque se esperaba una llave de cierre. Sin embargo, si nosotros revisamos detenidamente, no vemos ningún error de sintaxis y de hecho nuestro proyecto funciona correctamente. Aquí visual studio code nos ayuda a identificar los pares de llaves con colores. Por ejemplo, el color azul aquí representa el objeto que devolvemos como nuestro estado. En su interior tenemos categories, categories se define como un arreglo con corchetes de color amarillo. En su interior tenemos dos objetos y cada objeto tiene llaves de color rosado. Esto funciona correctamente tal como hemos visto. Sin embargo, la herramienta de ESLint espera una sintaxis distinta. Hay otra forma de escribir esto. Aquí tenemos un arreglo del tipo Category. Lo podemos escribir también de la siguiente manera, as Category, si es que se tratase de un solo objeto. Pero como es un arreglo, ponemos aquí los corchetes y también lo acepta. Categories es esto y se define como un arreglo de Category. Esta expresión nos indica el tipo de dato. Si guardamos por ejemplo y volvemos a correr nuestro linter. Vemos que el problema desaparece. Entonces la misma idea la vamos a aplicar sobre ProductList. Aquí estamos en ProductList. Y anteriormente usamos esta sintaxis. Ahora vamos a decir Product y poner aquí unos corchetes. Volvemos a correr el comando y ahora aparecen nuevos errores en ProductList. Primero que todo tenemos un warning en la línea 22. Aquí está la línea 22 y nos dice que onProductAdded no está en uso. Esto se debe a que anteriormente ProductList contenía ProductCards y cada card emitia un evento y ProductList tenía que volver a emitir el evento. Ahora no existe este método porque un ProductCard llama directamente al Store y se encarga de agregar el Product a través de un Action. Entonces esta sección de Methods la podemos eliminar y esta línea también porque ya no escuchamos a ningún evento llamado AddProduct. Aparte de ello también nos dice que si usamos una directiva v-for no tenemos que olvidarnos de agregar v-bind:key. Entonces vamos a agregar aquí key y vamos a indicar cuál es el identificador que representa a cada ProductCard. En este caso el ID del producto. Hasta aquí guardamos. Vamos a correr una vez más nuestro linter. Y en este caso vemos que persiste este error del v-for. Lo que pasa es que hemos agregado este key donde no es. Este key tiene que estar al mismo nivel que el v-for. Aquella etiqueta que lleve un v-for tiene que llevar un v-bind:key. que se puede escribir de manera breviada de esta forma, :key, e indicamos aquí un identificador para cada iteración de nuestro bucle for. Guardamos. Vamos a correr nuestro linter una vez más. Y tenemos solo un warning ahora. En TopBar. Vamos a cerrar por aquí. Vamos a abrir TopBar. Y simplemente vamos a eliminar este Import porque hemos visto que podemos usar RouterLink debido a que está definido de manera global. Corremos el linter. Y vemos que no hay ningún error. Estamos listos para empezar a refactorizar.

¿Tienes dudas?

Publicar pregunta

¡Comparte conocimiento!

X

Volver al índice

Regístrate

Inicia sesión para llevar un control de tu progreso.

Capítulos















































































79

ESLint













































Espera un momento ...

¿Te gustaría llevar mi curso de Laravel, gratis?

Sólo debes ingresar tus datos: