Patrones de Diseño de Componentes

Rate this content
Bookmark

¿Cómo se escribe un buen componente? En esta charla exploraremos varios patrones diferentes para escribir componentes mejores. Analizaremos técnicas para simplificar nuestros componentes, hacerlos más fáciles de entender y aprovechar al máximo los componentes que ya tenemos.

18 min
12 May, 2023

Video Summary and Transcription

La charla cubre componentes limpios y cuándo crear nuevos componentes, así como patrones para escribir componentes más limpios y los beneficios de los patrones VIP. La refactorización y la separación del código en componentes separados puede hacerlo más corto y más fácil de leer, reduciendo la complejidad. Se discute la importancia de no repetirse y los beneficios de usar componentes más pequeños para el rendimiento y la experiencia del desarrollador. Los componibles pueden ayudar a extraer lógica en componentes grandes y complejos, y los patrones se pueden incorporar en bibliotecas de componentes y sistemas de diseño.

Available in English

1. Introducción a Componentes Limpios y Patrones VIP

Short description:

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

Short description:

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

Short description:

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

Short description:

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Vue.js London Live 2021Vue.js London Live 2021
34 min
Everything Beyond State Management in Stores with Pinia
Top Content
When we think about Vuex, Pinia, or stores in general we often think about state management and the Flux patterns but not only do stores not always follow the Flux pattern, there is so much more about stores that make them worth using! Plugins, Devtools, server-side rendering, TypeScript integrations... Let's dive into everything beyond state management with Pinia with practical examples about plugins and Devtools to get the most out of your stores.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
Vue.js London Live 2021Vue.js London Live 2021
20 min
One Year Into Vue 3
Top Content
Vue 3 may still sound new to many users, but it's actually been released for over a year already. How did Vue 3 evolve during this period? Why did it take so long for the ecosystem to catch up? What did we learn from this process? What's coming next? We will discuss these questions in this talk!
Vue.js London Live 2021Vue.js London Live 2021
8 min
Utilising Rust from Vue with WebAssembly
Top Content
Rust is a new language for writing high-performance code, that can be compiled to WebAssembly, and run within the browser. In this talk you will be taken through how you can integrate Rust, within a Vue application, in a way that's painless and easy. With examples on how to interact with Rust from JavaScript, and some of the gotchas to be aware of.

Workshops on related topic

Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Top Content
Featured WorkshopFree
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.

Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.

Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem

Prerequisites:
IDE of choice (Inellij or VSC) installed
Nodejs + NPM
Vue.js London Live 2021Vue.js London Live 2021
117 min
Using Nitro – Building an App with the Latest Nuxt Rendering Engine
Top Content
Workshop
We'll build a Nuxt project together from scratch using Nitro, the new Nuxt rendering engine, and Nuxt Bridge. We'll explore some of the ways that you can use and deploy Nitro, whilst building a application together with some of the real-world constraints you'd face when deploying an app for your enterprise. Along the way, fire your questions at me and I'll do my best to answer them.
Vue.js London 2023Vue.js London 2023
137 min
TresJS create 3D experiences declaratively with Vue Components
Workshop
- Intro 3D - Intro WebGL- ThreeJS- Why TresJS- Installation or Stackblitz setup - Core Basics- Setting up the Canvas- Scene- Camera- Adding an object- Geometries- Arguments- Props- Slots- The Loop- UseRenderLoop composable- Before and After rendering callbacks- Basic Animations- Materials- Basic Material- Normal Material- Toon Material- Lambert Material- Standard and Physical Material- Metalness, roughness - Lights- AmbientLight- DirectionalLight- PointLights- Shadows- Textures- Loading textures with useTextures- Tips and tricks- Misc- Orbit Controls- Loading models with Cientos- Debugging your scene- Performance
Vue.js London Live 2021Vue.js London Live 2021
176 min
Building Vue forms with VeeValidate
Workshop
In this workshop, you will learn how to use vee-validate to handle form validation, manage form values and handle submissions effectively. We will start from the basics with a simple login form all the way to using the composition API and building repeatable and multistep forms.

Table of contents:
- Introduction to vee-validate
- Building a basic form with vee-validate components
- Handling validation and form submissions
- Building validatable input components with the composition API
- Field Arrays and repeatable inputs
- Building a multistep form
Prerequisites:
VSCode setup and an empty Vite + Vue project.
Vue.js London Live 2021Vue.js London Live 2021
116 min
Building full-stack GraphQL applications with Hasura and Vue 3
Workshop
The frontend ecosystem moves at a breakneck pace. This workshop is intended to equip participants with an understanding of the state of the Vue 3 + GraphQL ecosystem, exploring that ecosystem – hands on, and through the lens of full-stack application development.

Table of contents
- Participants will use Hasura to build out a realtime GraphQL API backed Postgres. Together we'll walk through consuming it from a frontend and making the front-end reactive, subscribed to data changes.
- Additionally, we will look at commonly-used tools in the Vue GraphQL stack (such as Apollo Client and Urql), discuss some lesser-known alternatives, and touch on problems frequently encountered when starting out.
- Multiple patterns for managing stateful data and their tradeoffs will be outlined during the workshop, and a basic implementation for each pattern discussed will be shown.
Workshop level

NOTE: No prior experience with GraphQL is necessary, but may be helpful to aid understanding. The fundamentals will be covered.
React Advanced Conference 2022React Advanced Conference 2022
206 min
Best Practices and Patterns for Managing API Requests and States
Workshop
With the rise of frameworks, such as React, Vue or Angular, the way websites are built changed over the years. Modern applications can be very dynamic and perform multiple API requests to populate a website with fresh content or submit new data to a server. However, this paradigm shift introduced new problems developers need to deal with. When an API request is pending, succeeds, or fails, a user should be presented with meaningful feedback. Other problems can comprise API data caching or syncing the client state with the server. All of these problems require solutions that need to be coded, but these can quickly get out of hand and result in a codebase that is hard to extend and maintain. In this workshop, we will cover how to handle API requests, API states and request cancellation by implementing an API Layer and combining it with React-Query.
Prerequisites: To make the most out of this workshop, you should be familiar with React and Hooks, such as useState, useEffect, etc. If you would like to code along, make sure you have Git, a code editor, Node, and npm installed on your machine.