Patrones de Diseño de Componentes

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

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

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

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.