DEV Community

loading...

3 Patrones de diseño 'resumidos asi nomas' (React)

Josmer Delgado
・3 min read

Antes de empezar les doy un poco de mi contexto, previo a trabajar con React tuve un corto, pero muy enriquecedor, paso por el mundo iOS con Swift. Dentro de la comunidad se tiende a discutir mucho sobre los distintos "patrones de diseño" que se recomiendan utilizar en esta tecnología tales como: MVC, MVP, MVVM, VIPER, etc….

Al empezar a trabajar con React pregunte varias veces sobre patrones de diseño, sentí en muchas oportunidades que me veían con cierta extrañeza como si fuese un tema ajeno; al leer la documentación de esta librería vi que ellos mismos se definen como la V (View) de MVC, eso quiere decir que esta herramienta solo se encargará de lo que el usuario verá, “si o no Linda Blair?”.

LindaBlair

No contento con estas respuestas indague un poco más y conseguí un buen número de patrones de diseño para crear aplicaciones de primera calidad.

Pequeña aclaración los “Patrones de diseño” no son más que sugerencias, como tal tienen ventajas, pero ninguna sirve como bala de plata para solucionar todos los problemas. “Quedó Claro?”
pinocho

Presentational and Container Components

La primera vez que leí sobre esto el escrito fue del ya famoso Dan Abramov, quien recomendaba tener dos tipos de componentes: un contenedor con la lógica de negocios, eventos asíncronos, y todo lo ajeno a la renderización; y uno que solo se encargaría de mostrar solo con lógica de visualización.

Esto facilita el debuggear, el testing y la legibilidad del código, características que benefician en gran medida el proceso de desarrollo y prueba de la aplicación… “Mira como te mira Conan”
conan

Es cierto! Si bien en el mismo artículo el autor hace una aclaración de que, en su momento esto generaba un gran beneficio, hoy en día no se tiende a usar y se sustituyó con hooks. Para quienes ya conocen esta herramienta básicamente podríamos sustituir ese Container component por uno o más customs Hooks.

Context API

Si vienes trabajando desde hace algún tiempo con React debes estar familiarizado con el término “Prop Drilling”, pero si no, esto hace referencia a pasar una prop desde un componente muy alto en la jerarquía a uno que está muy abajo, teniendo que pasar las props entre distintos componentes que no hacen uso ella solo sirven de pasamanos. Esto es un problema, ya que afecta la legibilidad y la trazabilidad de nuestro código, además de que repetimos código que no utilizamos.

"Y aca empieza la batalla del equipo de React contra el Prop Drilling y como es batalla y es final es ultra violenta."
ultraViolenta

Así llega Context Api, la cual nos permite compartir y acceder a data entre un gran número de componentes con distintos niveles de jerarquía. Evitando así el problema de pasar props a través de distintos niveles.

Render Props y High Order Component(HOC)
Estos patrones vienen disminuyendo su “fama y poder” desde la llegada del “new kid on the block“ react hooks, pero son herramientas muy interesante a tener en el cinturón.

Render Props: propone que en lugar de recibir un componente como prop o hijo, reciba una función que retorna un componente donde los parámetros van a ser establecidos por el componente padre, permitiendo una fácil interacción entre ambos componentes, y una mayor separación de responsabilidades.

HOC: este patrón de diseño nos facilita el envolver componentes pasandole props, mediante una función que recibe un componente y retorna el mismo componente con un nuevo padre. Esta herramienta tiende a mejorar la reutilización y por consiguiente la mantenibilidad del código.

"y ahora que sabe esto…"
GoAndTellYourFriend

ah y haganle caso a la tia Marta… Suscribanse al canal de te lo resumo todos los chistes y referencias son sacados de ahi.

Para ahondar más sobre estos temas:
https://reactjs.org/docs/higher-order-components.html
https://reactjs.org/docs/render-props.html
https://kentcdodds.com/blog/how-to-use-react-context-effectively
https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0
https://reactpatterns.com/

Discussion (0)