5 patrones de componentes que TENÉS que saber en React

Hola gente, ¿cómo están? Bueno, hoy vamos a ver un poco patrones y maneras de manejar datos en componentes que lo vamos a hacer en React, pero puede ser aplicable prácticamente a cualquier tipo de framework eh de frontend tradicional basado en componentes. Esto originalmente fue un stream de más de 2 horas, pero como yo no me vería un streaming de 2 horas, dije, vamos a hacer algo un poquito más reducido para explicar alguno de los patrones tradicionales. Vamos a venir acá a la pantalla y lo

vamos a manejar todo en storybo. Casi todos los componentes que nosotros vamos a visualizar acá son el mismo componente, solamente que creado de maneras diferentes. Vamos a empezar con lo típico y básico, que no creo que tenga este nombre que le dimos acá, pero es como para que lo entiendan, que son los componentes básicos que suelen manejar las propiedades, las props, vía hacerlo de manera spread, o sea, recibiendo en un componente hipotético

property card, que sería este componente que nos muestra como información acerca de una propiedad. Simplemente obtener todas las props, siendo por ejemplo el título, la locación, el precio, habitaciones y más. Simplemente spreadeando, pasando las props de esta manera, haciendo un spread, que a mí no me gusta mucho porque cada vez que tenés que ver qué propiedades le estás pasando a este componente, tenés que recurrir a simplemente ver los tipos. No es tan

fácil de verlo como capaz cuando lo haces de manera manual. Cuando lo haces de manera manual, la desventaja que tiene es que se vuelve mucho más verboso. Entonces, está todo bien mientras no estés haciendo literalmente cada propiedad como estarías haciendo acá, ni tampoco tengas muchos componentes en vista que están haciendo exactamente el mismo patrón, porque nada, si no se vuelve un uno a uno gigante que no queda muy bueno. Pero estos son los componentes tradicionales

que solemos ver, o sea, es el patrón más común a la hora de crear componentes y están perfectos para la mayoría de los casos. van a ver que la mayoría de los componentes que estamos manejando acá van a ser simplemente estos componentes que presentan información y no tienen tanta lógica de negocio. Capaz algunos patrones empiezan a hacer un poquito más de sentido cuando hablamos de lógica de negocio. Después tenemos el que se llama la value prop o la data prop o como le quieran

llamar, que es básicamente el mismo patrón que teníamos antes, pero la diferencia es que se maneja mediante una prop sola. Por ejemplo, el la propu o la prop data data son las que más se usan. A mí me gusta usar value porque entra un poco en este concepto de componentes que pueden ser cualquier cosa. Por ejemplo, un componente que presenta datos, recibe una propu simplemente presenta la información. Cuando hablamos de inputs, por ejemplo,

un text field, un select field o lo que sea, también maneja un value, que es el valor que corresponde a ese componente y generalmente también recibe una propon y devuelve un value nuevo. Entonces, por eso lo suelo llamar value, pero puede ser lo que ustedes quieran. La ventaja de esto es que sabemos que tenemos todo lo correspondiente para presentar la información en pantalla en una prop sola y después si tenemos que agregar props diferentes que modifiquen la forma de presentar datos o necesita

tener callbacks o lo que sea, van a estar en lugares separados. Si nosotros vemos el anterior que teníamos todas las props en en un nivel root, vamos a decirle, y tenemos que agregarlo una propiedad que no corresponde a la a la propiedad property en sí, va a estar mezclada junto con las otras props. Entonces, perdemos un poco esa visualización fácil de qué corresponde a la propiedad en sí y qué corresponde a propiedades del componente que