Component Design Patterns

Gracias por esa introducción. Fue genial. Es realmente increíble estar aquí hoy porque exactamente hace un año, renuncié a mi trabajo y me dediqué a enseñar sobre Vue y a escribir artículos y crear cursos y libros y cosas así a tiempo completo. Así que, gracias por tenerme aquí.

Me gustaría hablarles sobre componentes limpios. Y al hablar con diferentes personas en la comunidad y ver qué preguntas se hacen en Twitter y cosas que recibo en mi bandeja de entrada de correo electrónico, he visto dos preguntas fundamentales surgir 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, por ejemplo, ¿es este componente demasiado grande o demasiado complicado? ¿Deberíamos extraerlo a algo más? Y esto es algo con lo que lidiamos todos los días. Pero una vez que hemos resuelto eso, también necesitamos averiguar cómo hacerlo bien. Y no se trata solo de mover piezas de código en tu sistema de archivos y hacer todo tipo de cosas así. Pero realmente queremos simplificar nuestra base de código y hacer nuestro código más fácil de usar.

Así que en esta charla, cubriremos tres cosas principales. Patrones y métodos para cómo escribir componentes más limpios y simplificar nuestro código. Y solo arañaremos la superficie de estas dos preguntas porque son preguntas bastante grandes. Pero con suerte, saldrás de aquí con un par de cosas que puedes aplicar. Así que vamos a cubrir algunos patrones allí. Y al final, también vamos a cubrir cuándo no crear nuevos componentes. Así que el primer conjunto de patrones es sobre los VIPs. Y son realmente agradables porque básicamente podemos mirar 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á allí. Y sabemos que podemos hacer esto por dos razones. La primera es que cada rama de este condicional está semánticamente relacionada. Así que el código que va en cada rama diferente trabaja junto con el mismo propósito. Puede que conozcas esto como cohesión. Pero realmente, solo estamos hablando de código que trabaja junto. Y la segunda razón es similar. Relacionada con eso. Y es que no solo cada rama trabaja junta, sino que cada rama diferente es distinta. De lo contrario, no tendríamos un condicional. Simplemente, ya sabes, haríamos que tu código se ejecute. Así que para ver esto con más detalle, vamos a echar un vistazo a 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. Así que ya sea que tengas 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 todos, como, los diferentes artículos relacionados. Así que este es el código para ese componente. Y no espero que leas todo esto ahora mismo. Tendré mis diapositivas disponibles más tarde, solo para que lo sepas.

Sí, así que puedes ver que en el nivel superior tenemos un VF allí con los dos cuerpos diferentes de esta rama aquí. Y hacen cosas diferentes. Una es una versión colapsada. Una es una versión expandida. Pero aunque son similares, aunque son diferentes, comparten algo de código allí. Así que, 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 de un vistazo. Podemos ver fácilmente artículo colapsado y artículo expandido y saber que esa es la intención de lo que hace este código. Y esto es lo que es el código autodescriptivo. Nos dice lo que hace mientras lo leemos sin tener que, ya sabes, pensar profundamente sobre cuáles son las diferentes condiciones y todas las diferentes cosas 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 V4 aquí y podemos realmente trasladarla al componente hijo. Y la razón detrás de esto es similar a preferir métodos como filter y map y reduce en lugar de simplemente escribir tu bucle for cada vez. Entonces, ¿qué hacemos cuando las ramas son, aunque distintas, bastante similares? Bueno, algo que podemos hacer con este VF aquí es que podemos tomar ese VF y realmente trasladarlo al componente hijo. Así que estamos tomando la complejidad de este componente padre y poniéndola en el componente hijo. Así que en nuestro caso aquí, tenemos este componente padre aquí con nuestros componentes colapsados y expandidos. Y respectivamente, se ven algo así. Así que tenemos un enlace Nuxt en cada uno. Y el expandido también tiene algunas etiquetas de párrafo 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 convertido en un componente que es un poco más largo, pero no está tan mal. Y por supuesto, tenemos que tomar ese condicional y ahora moverlo al hijo. Así que tenemos algunas cosas diferentes sucediendo aquí. Tenemos este v show, donde tenemos que cambiar basado en esta prop collapse.

Y luego las etiquetas de párrafo en la parte inferior, vamos a renderizar condicionalmente también. Y luego también tenemos que calcular la clase, porque uno es flexbox, el otro es grid. En teoría, puedes hacer que sea una grid de una sola columna dentro de flexbox, pero este es solo el primer paso en nuestro refactorización aquí. Así que al final, al empujar este vfConditional del padre al hijo, nuestro componente padre ahora se vuelve un poco inútil, y quizás podríamos incluso deshacernos de él.

Pero tenemos un problema bastante grande, en mi mente. Y eso nos deja con cuándo no crear este componente. Y así, tenemos este componente corto. Pero porque hemos tomado dos componentes que hacen cosas diferentes, y los hemos combinado juntos, en realidad hemos hecho este componente mucho más complejo. Y al practicar esta charla, y escribir mis diapositivas, después de un rato, 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 collapse 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á pasando, es mucho de pensar, mucho de paso a paso mirando y tratando de determinar qué está pasando aquí. Y así, esto es en última instancia una cuestión de, ¿es mejor mantener, es mejor eliminar el código duplicado o no? Y a muchas personas les gusta seguir 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 en realidad un error. Así que queremos volver a lo que teníamos antes con este componente padre aquí. Y luego tomar estos componentes article collapsed y article expanded y, sí, y separarlos. Así que tenemos dos componentes simples en lugar de uno más complejo, más difícil de entender.

Así que... esos son los tres patrones que quería cubrir aquí. Y ahora es el final de la charla donde puedo promocionarme descaradamente por un momento. Y estoy trabajando en un nuevo curso que debería salir en un par de meses que habla más sobre estos tipos de patrones y profundiza más sobre cómo creamos nuevos componentes. ¿Cómo hacemos eso bien? Y un par de otros conceptos relacionados. Así que si quieres más información sobre eso, puedes seguirme en Twitter o en cualquier lugar en línea y estaré hablando sobre eso. También soy... soy el instructor de Mastering Next 3 que es en asociación con Vue School y si quieres aprender Next 3, cómo hacer desarrollo full-stack, cubrimos todo desde lo básico hasta la autenticación e integración con Stripe y todo ese tipo de cosas con eso. Y luego, por supuesto, también está este libro si quieres conseguirlo en línea. También hay una versión en e-book para que no tengas que tener la copia física. Y ahí están mis enlaces e información. ¡Muchas gracias! Por favor, tomen asiento, tomen asiento. Hubo tantas buenas preguntas pero ahora mismo, y me encanta que esta todavía esté, oh esta todavía está ahí con 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 sacaste? Porque podría necesitar pedir una yo mismo. Así que hace unos años mi esposa me consiguió una camiseta de Vue para mi cumpleaños pero ya sabes, se pone vieja y desgastada y así que en realidad diseñé esta camiseta yo mismo y la mandé a imprimir personalizada. ¡Genial, genial! Así que ahora tienes algo de inspiración puedes ir y mandar a imprimir tu propia camiseta de Vue.

Tenemos algunas otras preguntas aquí, voy a saltar a las que son relevantes para tu charla. Tenemos una que dice que los componentes más pequeños a menudo pueden ser más eficientes. 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. Así que es un poco de una pregunta larga, pero hay algo de sustancia ahí, encontrar el momento adecuado para cambiar de dirección.

Sí, así que no tengo tanta experiencia en la optimización del rendimiento de aplicaciones web, así que no puedo hablar mucho sobre ese aspecto. Pero creo que en general existe 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 rendimiento en una capacidad mental manera. Sí, definitivamente. Es un poco como lo que Evan estaba diciendo también, hay rendimiento y está qué tan feliz estás como desarrollador al escribir el código. Sí, experiencia del desarrollador. Creo que la experiencia del desarrollador es algo que quieres asegurarte de optimizar también.

Y otra que es un poco una pregunta muy relacionada con Vue, para componentes grandes y complejos escritos con la API de composición, ¿cómo recomiendas estructurar el código dentro de la etiqueta de script? Sí. Así que, una cosa que realmente me gusta es, como, podemos crear estos composables para, como, podemos crear estos composables, y así se hace realmente fácil en realidad extraer la lógica de tu componente. Y así puedes hacer esto, como, con composables reutilizables que podrías usar en múltiples componentes diferentes, pero también puedes hacer, como, una cosa uno a uno donde tal vez tienes un componente que es más complejo y no puedes, no hay una manera fácil de hacerlo más pequeño. Pero podrías tomar, ya sabes, tomar secciones de ese script y sacarlas en tal vez tienes tres composables diferentes. Y esos composables solo se usan en ese componente. Pero al menos te permite desglosar esa lógica de una manera que está organizada y es fácil de entender.

Genial. Y hagamos una pregunta más, porque sé que se nos está acabando el tiempo. ¿Cómo estos patrones, esta es de Edward, cómo estos patrones se traducen a una biblioteca de componentes más abstracta o sistema de diseño? Si ya estás usando una biblioteca de componentes o sistema de diseño y también tienes estos otros patrones que quieres traer a la mesa, ¿cómo los incorporarías? Sí. Creo que es un enfoque bastante similar, diría yo. Trabajar en una biblioteca de componentes hay mucho más pensamiento que entra en la API, como Eduardo estaba hablando sobre hacerla más fácil de usar. Y creo que eso puede de alguna manera afectar cómo estructuras tus componentes.

Pero sí. Genial. Genial. Gracias. Ahora sé que tienes algunas copias extra del libro, no solo para las preguntas que se hicieron. Así que si hiciste una pregunta, tu respuesta fue leída. Y tal vez si también solo quieres echar un vistazo al libro, diría definitivamente ve y encuentra a Michael arriba después de esta charla también. Definitivamente podrá responder cualquier otra pregunta que no pudimos abordar.