1. Introducción a Componentes Limpios y Patrones VIP
Hablaré sobre componentes limpios y cuándo crear nuevos componentes. Cubriremos patrones para escribir componentes más limpios y cuándo no crear nuevos componentes. También exploraremos los patrones VIP y sus beneficios.
Gracias por esa introducción. Es realmente genial estar aquí hoy porque exactamente hace un año, renuncié a mi trabajo y me dediqué a enseñar y escribir artículos, crear cursos y libros y cosas por el estilo a tiempo completo. Así que, gracias por tenerme aquí. Me gustaría hablarles sobre los componentes limpios. Al hablar con diferentes personas en la community y ver las preguntas que se hacen en Twitter y las cosas que recibo en mi correo electrónico, he visto que surgen dos preguntas fundamentales una y otra vez. La primera es que queremos saber cuándo creamos nuevos componentes. ¿Creamos componentes más pequeños? ¿Creamos componentes más grandes? Y, ¿este componente es demasiado grande o demasiado complicado? ¿Deberíamos sacarlo y ponerlo en algo más? Y esto es algo con lo que lidiamos todos los días. Pero una vez que lo hemos descubierto, también necesitamos descubrir cómo hacerlo bien. Y no se trata solo de mover trozos de código en nuestro sistema de archivos y hacer todo tipo de cosas así. Sino que realmente queremos simplificar nuestra base de código y hacer que nuestro código sea más fácil de usar. Así que en esta charla, cubriremos tres cosas principales. Patrones y métodos para escribir componentes más limpios y simplificar nuestro código. Y solo rascaremos la superficie de estas dos preguntas porque son bastante grandes preguntas. Pero espero que te vayas de aquí con un par de cosas que puedas aplicar. Así que vamos a cubrir algunos patrones aquí. Y al final, también vamos a hablar sobre cuándo no crear nuevos componentes. Así que el primer conjunto de patrones se trata de VIPs. Y son realmente agradables porque básicamente podemos ver las diferentes ramas. Y la mayoría de las veces, podemos extraer el código que está en el cuerpo de cada rama sin necesidad de saber mucho más sobre el código que está sucediendo allí. Y sabemos que podemos hacer esto debido a dos cosas. La primera es que cada rama de esta condicional está relacionada semánticamente. Entonces, el código que va en cada rama diferente funciona junto para el mismo propósito. Puede que conozcas esto como cohesión. Pero realmente, solo estamos hablando de código que funciona junto. Y la segunda razón es similar. Relacionada con eso. Y es que no solo cada rama funciona junto, sino que cada rama diferente es distinta. De lo contrario, no tendríamos una condicional. Simplemente, ya sabes, ejecutaríamos tu código. Para ver esto en
2. Explicación del Código de Componentes y Refactorización
Es un componente que muestra una lista de artículos en mi blog. Tiene una vista expandida y una versión colapsada. Al refactorizar y separar el código en componentes separados, se vuelve más corto y más fácil de leer. También podemos trasladar la lógica al componente hijo, reduciendo la complejidad en el componente padre. El resultado es un componente de visualización de artículos con código combinado y una condicional basada en la propiedad de colapso.
Para más detalles, vamos a ver un ejemplo. Y este ejemplo es, oh, olvidé conectarme al Wi-Fi aquí, así que no veremos este ejemplo. Así que solo te daré una explicación rápida. Es un componente que muestra una lista de artículos en mi blog. Puedes tener una vista expandida que muestra, como, la fecha y la descripción, o puedes tener la versión colapsada que muestra al final de la publicación del blog, todas las, como, los diferentes artículos relacionados. Entonces este es el código para ese componente. Y no espero que lo leas completo en este momento. Tendré mis diapositivas disponibles más adelante, así que solo para que lo sepas. Sí, puedes ver que en el nivel superior tenemos un VF allí con los dos cuerpos diferentes de esta rama aquí. Y hacen cosas diferentes. Uno es una versión colapsada. Uno es una versión expandida. Pero aunque son similares, aunque son diferentes, comparten algo de código allí. Entonces, se ven similares. Pero podemos refactorizar eso extrayéndolo en componentes separados. Y no solo este código es más corto, sino que es mucho más fácil de leer a simple vista. Podemos ver fácilmente 'article-collapsed' y 'article-expanded' y saber que esa es la intención de lo que hace este código. Y así es como es el código autoexplicativo. Nos dice qué hace a medida que lo leemos sin tener que pensar profundamente en las diferentes condiciones y todas las cosas diferentes que están sucediendo.
Y un patrón rápido que quería mencionar aquí pero no tengo tiempo para profundizar es que podemos tomar toda esta lógica de V4 aquí y realmente podemos empujarla al componente hijo. Y el razonamiento detrás de esto es similar a preferir métodos como filter y map y reduce en lugar de escribir tu bucle for cada vez. Entonces, ¿qué hacemos cuando las ramas, aunque sean distintas, son bastante similares? Bueno, algo que podemos hacer con este VF aquí es tomar ese VF y realmente empujarlo hacia abajo en el componente hijo. Entonces estamos tomando la complejidad de este componente padre y poniéndola en el componente hijo. Entonces, en nuestro caso, tenemos este componente padre con nuestros componentes colapsados y expandidos. Y respectivamente, se ven algo así. Entonces tenemos un enlace de Nuxt en cada uno. Y el expandido también tiene algunos párrafos allí. Y si lo combinamos, podríamos obtener algo como este componente de visualización de artículos, donde hemos tomado el código que es similar y lo hemos juntado y lo hemos convertido en un componente un poco más largo, pero no está mal. Y, por supuesto, tenemos que tomar esa condicional y ahora moverla al componente hijo. Entonces tenemos algunas cosas diferentes sucediendo aquí. Tenemos este v-show, donde tenemos
3. Refactorización y Promociones
Combinamos dos componentes que hacen cosas diferentes, lo que hace que el componente sea más complejo. Hubo un error en el código debido a la complejidad. No repetirse se trata de conocimiento e intención, no solo de duplicación de código. Deberíamos volver al componente padre y separar los componentes colapsados y expandidos. Estoy trabajando en un nuevo curso y también enseñando Mastering Next 3 con Vue School. Puedes encontrar más información en Twitter y mis otras plataformas en línea.
para cambiar según esta propiedad de colapso. Y luego las etiquetas de párrafo en la parte inferior, también vamos a representar condicionalmente. Y también tenemos que calcular la clase, porque uno es flexbox y el otro es grid. En teoría, puedes hacer que sea una cuadrícula de una sola columna dentro de flexbox, pero este es solo el primer paso en nuestra refactorización aquí. Entonces, al final, al empujar este vfConditional del padre al hijo, nuestro componente padre ahora se vuelve un poco inútil, e incluso podríamos deshacernos de él. Pero tenemos un problema bastante grande, en mi opinión. Y eso nos lleva a cuándo no crear este componente. Y así, tenemos este componente corto. Pero debido a que hemos tomado dos componentes que hacen cosas diferentes y los hemos combinado, en realidad hemos hecho que este componente sea mucho más complejo. Y al practicar esta charla y escribir mis diapositivas, después de un tiempo, me di cuenta de que en realidad hay un error en este código, que no me di cuenta al principio, porque es más complejo. Este V show, este colapso aquí, debería haber eliminado esa negación. Y así, al principio, es fácil pasar por alto ese tipo de cosas, porque hay muchas cosas sucediendo aquí, y para entender este código y lo que está sucediendo, es mucho pensar, mucho mirar paso a paso y tratar de determinar qué está sucediendo aquí. Y así, esto es en última instancia una cuestión de si es mejor mantener, es mejor eliminar código duplicado o no. Y a mucha gente le gusta seguir el principio DRY, no te repitas, pero en realidad, no te repitas se trata más del conocimiento y la intención detrás del código y no de los caracteres reales en la pantalla. Y así, aunque esos componentes se ven iguales, en realidad representan intenciones muy diferentes. Y así, combinarlos juntos, en este caso, fue un error. Así que queremos volver a lo que teníamos antes con este componente padre aquí. Y luego tomar estos componentes de artículo colapsado y artículo expandido y, sí, separarlos. Así que tenemos dos componentes simples en lugar de uno más complejo, más difícil de entender.
Entonces... eso es todo lo que quería cubrir aquí. Y ahora es el final de la charla donde puedo promocionarme descaradamente por un momento. Estoy trabajando en un nuevo curso que debería salir en un par de meses y que habla más sobre este tipo de patterns y profundiza más en cómo creamos nuevos componentes. ¿Cómo lo hacemos bien? Y un par de conceptos relacionados más. Así que si quieres más información sobre eso, puedes seguirme en Twitter o en cualquier lugar en línea y estaré hablando de eso. También soy el instructor de Mastering Next 3, que es en colaboración con Vue School y si quieres aprender Next 3, cómo hacer desarrollo full-stack, cubrimos todo desde lo básico hasta la authentication y la integración con Stripe y todas esas cosas con eso. Y luego, por supuesto, también está este libro si quieres obtenerlo en línea. También hay una versión de libro electrónico para que no tengas que tener la copia física. Y ahí están mis enlaces e información. ¡Muchas gracias! Por favor, toma asiento, toma asiento. Hubo muchas buenas preguntas pero ahora, y me encanta que esta siga, oh, esta sigue ahí con
4. Michael's T-shirt y Estructura de Componentes
La camiseta de Michael es increíble. Él la diseñó él mismo y la mandó a imprimir personalizada. Los componentes más pequeños pueden mejorar el rendimiento, pero se debe considerar la complejidad. La experiencia del desarrollador también es importante. Al estructurar el código en componentes grandes y complejos, el uso de composables puede ayudar a extraer la lógica. Los patrones se pueden incorporar en bibliotecas de componentes y sistemas de diseño.
una de las preguntas más votadas, y es una de mis preguntas personales. ¿Han notado la camiseta de Michael? Es bastante increíble. ¿De dónde la obtuviste? Porque tal vez necesite pedir una para mí. Hace unos años, mi esposa me regaló una camiseta de
Vue para mi cumpleaños, pero ya saben, se va desgastando y se pone vieja, así que en realidad diseñé esta camiseta yo mismo y la mandé a imprimir personalizada. ¡Genial, genial! Ahora tienen algo de inspiración para imprimir su propia camiseta de
Vue. Tenemos algunas otras preguntas aquí, solo voy a responder las que son relevantes para su charla. Tenemos una que dice que los componentes más pequeños a menudo pueden tener un mejor rendimiento. No cargan ningún
CSS o JS cuando no es necesario. Pero ¿cuándo la complejidad de los componentes más pequeños supera los beneficios de rendimiento y esto está relacionado con cuándo no crear un nuevo componente? Es una pregunta un poco larga, pero tiene sustancia, encontrar el momento adecuado para hacer el cambio.
Sí, no tengo tanta experiencia en la optimización del rendimiento de las aplicaciones web, así que no puedo hablar mucho de ese aspecto. Pero en general, creo que hay esta pregunta de ¿cuán pequeño es demasiado pequeño? Porque eventualmente no quieres tener 30 archivos abiertos y cada archivo tiene cinco líneas, porque el cambio de contexto entre cada una de esas cosas es lo que lo hace difícil. Así que tal vez el rendimiento en términos de capacidad mental también es importante. Sí, definitivamente. Es como lo que Evan también dijo, hay rendimiento y hay qué tan feliz estás como desarrollador al escribir el código. Sí, la experiencia del desarrollador. Creo que la experiencia del desarrollador es algo en lo que también debes optimizar. Y otra pregunta relacionada con Vue, para componentes grandes y complejos escritos con la API de composición, ¿cómo recomendarías estructurar el código dentro de la etiqueta de script? Sí. Una cosa que me gusta mucho es, como, podemos crear estos composables para, como, podemos crear estos composables, y así es muy fácil extraer la lógica de tu componente. Y puedes hacer esto, como, con composables reutilizables que puedes usar en diferentes componentes, pero también puedes hacerlo, como, uno a uno donde tal vez tienes un componente que es más complejo y no hay una forma fácil de hacerlo más pequeño. Pero podrías tomar, ya sabes, tomar secciones de ese script y sacarlas, tal vez tengas tres composables diferentes. Y esos composables solo se usan en ese componente. Pero al menos te permite separar esa lógica de una manera organizada y fácil de entender. Genial. Y hagamos una pregunta más, porque sé que nos estamos quedando sin tiempo. ¿Cómo se traducen estos patrones, esta es de Edward, ¿cómo se traducen estos patrones a una biblioteca de componentes o a un sistema de diseño más abstracto? Si ya estás usando una biblioteca de componentes o un sistema de diseño y también tienes estos otros patrones que quieres incorporar, ¿cómo los incorporarías? Sí. Creo que es un enfoque bastante similar, diría yo. Trabajar en una biblioteca de componentes implica mucho más pensamiento en la API, como Eduardo mencionó sobre hacerla más fácil de usar. Y creo que eso puede afectar de alguna manera cómo estructuras tus componentes. Pero sí.
Genial. Genial. Gracias. Ahora sé que tienes algunas copias adicionales del libro, no solo para las preguntas que se hicieron. Así que si hiciste una pregunta y se leyó tu respuesta. Y tal vez si también quieres echar un vistazo al libro, definitivamente ve y encuentra a Michael arriba después de esta charla también. Definitivamente podrá responder cualquier otra pregunta que no hayamos podido responder. Pero Michael, muchas gracias. Aplausos para Michael.
Vue.js London Live 2021
Comments