How do you decide to use useReducer instead of useState?
In general you can always use reducers, technically useState is a simplified version of useReducer.
But then, Why use useReducer?
Although it looks more complex, using it gives you great advantages.
The first advantage is encapsulation and abstraction.
useReducer uses a reducer function that lives outside of the component and is not affected by re-renders. It also simplifies your code by ISOLATING the state logic in a function.
Another advantage is that you can handle more complex states with different update logics and in an "atomic" way.
The reducer function receives the current state and an object that we commonly call an action.
Depending on the action, the function will return a new state.
This simple definition allows you to modify complex states based on different actions or "events" by removing the update logic from the component.
When you use useState it is usually for simple, non-interrelated states. Also the update logic (the calls to your setState) happen directly in the component.
But going back to the first question
When to use useReducer?
There is no particular hard rule but a good "rule of thumb" is that if your component has 3/4 or more useState you will benefit from using useReducer. Even more if those states are dependent.
Now if you have such a complex state there is probably another type of problem The state modeling or component composition is off. It is a "code smell".
Finally another advantage when using useReducer is that it allows you to create more complex patterns like "State Reducer".
Knowing and using more complex hooks allows you to implement "advanced" components as in this (ongoing) course in @eggheadio
If you speak Spanish and want to know more about React, javascript and web development join the MicroBytes newsletter !!
The course "React from sractch" is soon to be published. microbytes.matiashernandez.dev
And follow me on Twitter for more content
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Al escribir componentes React.
¿Cuando decides usar useReducer en vez de useState?
En general puedes usar reducers siempre, técnicamente useState es una versión simplificada de useReducer.
¿Por que usar useReducer?
Si bien se ve más complejo usarlo te da grandes ventajas
La primera ventaja es encapsulacion y abstracción.
useReducer utiliza una función reducer que vive fuera del componente no siendo afectada por los re-renders y además simplifica tu código por que AISLA la lógica de estado en una función.
Otra ventaja es que puedes manejar estados más complejos con lógicas de actualización diferente y de manera "atómica".
La función reducer recibe el estado actual y un objeto que comúnmente llamamos acción.
Dependiendo de la acción la función retornará un nuevo estado.
Becoming an @eggheadio instructor is for sure the biggest achievement in my career as dev.
I was just talking about this very same topic with @RealChrisSean and now I see that I been featured
Hablemos de "State management" y porqué es "complejo".
¿Que es el estado de una App?
En una versión muy simple estado son datos que cambian en el tiempo y que usamos para definir que se muestra o no al usuario.
Pero: ¿de donde vienen esos datos?
Esta pregunta es quiza la "piedra angular" para un modelo mental sobre el manejo de estado.
No todo el estado es igual ni proviene de las mismas fuentes.
Podemos definir a lo menos 2 categorías de estado
- UI state
- Server State
(shouts @tannerlinsley for this idea)
UI State: el estado que representa aspectos de la interfaz exclusivamente y que es modificado por acciones del usuario por ejemplo ejemplo un modal abierto/cerrado, el valor de un input o un menú.
Es un estado de fácil acceso, efímero y sincrono y es "simple" de manejar
¿Por que el desarrollo web se ha vuelto tan complejo?
En mi opinión tiene que ver con principalmente dos razones: 1. Los requerimientos han crecido y las expectativas de los usuarios y clientes han aumentado respecto a que es y no posible "en la plataforma"
...
2. La web (como la ideó Sir @timberners_lee) no fue ni está "arquitecturada" (palabra inventada) para lo que la estamos usando hoy.
La web fue ideada e implementada como una plataforma para compartir documentos de hiper texto. "Documentos" (subrayo ésto) que se enlazan con otros
He ahí que el lenguaje principal de la web sea HTML. Javascript vino a ser un parche sobre los motores de los browsers para darle algo de interactividad y dinamismo a esos documentos
Q me disculpe @Pa__tty pero usar la vulnerabilidad de NNA como argumento para la presencialidad en clases de colegio es incongruente.
1ero que edades? Acaso todos los estudiantes podrán llevar a cabo los protocolos de autocuidado?
2do hablan de la vulnerabilidad de estudiantes...
Si hablamos de estudiantes vulnerables lo más seguramente también serán establecimientos de escasos recursos por lo que es muy difícil asegurar protocolos de seguridad (en cuanto a insumos).
Vulnerabilidad, si es económica entonces hablamos de uso de transporte público, es decir, espacios aglomerados y sabemos que los menores no serán vacunados, ergo, exposición a posibles contagios ya que aun no se alcanza inmunidad de grupo.
He leído varias veces este tipo de preguntas.
¿Se puede usar React con....? O ¿Cómo usar React con X...? Siendo X alguna tecnología para desarrollo de APIS como Rails, Django, PHP/Laravel,.Net y en general la respuesta es la misma.
2 opciones posibles (no sólo para React) 🧵
La primera opciones es simple. Crea una api Rest o un endpoint graphql y listo.
React (y otros frameworks) pueden funcionar "solos" (una SPA). Es decir se distribuye un grupo de archivos estáticos que son servidos en algún CDN y se comunican con el servidor mediante alguna API.
Esto quiere decir que React (y los demás) son agnósticos de la tecnología de servidor usada ya que el medio de comunicación son solo llamadas HTTP (POST, GET, etc) que transmiten json.