Ir al contenido principal

Acciones

Traducción Beta No Oficial

Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto. ¿Encontraste un error? Reportar problema →

Preguntas Frecuentes de Redux: Acciones​

¿Por qué type debe ser una cadena? ¿Por qué mis tipos de acción deberían ser constantes?​

Al igual que con el estado, las acciones serializables permiten varias características clave de Redux, como la depuración de viaje en el tiempo y la grabación y reproducción de acciones. Usar algo como un Symbol para el valor de type o verificaciones instanceof para las acciones mismas rompería esa funcionalidad. Las cadenas son serializables y fácilmente auto-descriptivas, por lo que son una mejor opción. Ten en cuenta que sí es aceptable usar Symbols, Promises u otros valores no serializables en una acción si está destinada a ser usada por middleware. Las acciones solo necesitan ser serializables cuando llegan al store y se pasan a los reductores.

No podemos imponer acciones serializables de manera confiable por razones de rendimiento, por lo que Redux solo verifica que cada acción sea un objeto simple y que type sea una cadena. El resto depende de ti, pero puedes descubrir que mantener todo serializable ayuda a depurar y reproducir problemas.

Encapsular y centralizar fragmentos de código de uso común es un concepto clave en programación. Si bien ciertamente es posible crear objetos de acción manualmente en todas partes y escribir cada valor type a mano, definir constantes reutilizables facilita el mantenimiento del código. Si colocas las constantes en un archivo separado, puedes comprobar errores tipográficos en tus sentencias import para no usar accidentalmente la cadena incorrecta.

Más información​

Documentación

Discusión

¿Existe siempre una correspondencia uno a uno entre reductores y acciones?​

No. Sugerimos escribir pequeñas funciones reductoras independientes, cada una responsable de actualizar una porción específica del estado. Llamamos a este patrón "composición de reductores". Una acción determinada podría ser manejada por todos, algunos o ninguno de ellos. Esto mantiene los componentes desacoplados de los cambios reales de datos, ya que una acción puede afectar diferentes partes del árbol de estado, y no es necesario que el componente sea consciente de esto. Algunos usuarios eligen vincularlos más estrechamente, como en la estructura de archivos "ducks", pero definitivamente no hay una correspondencia uno a uno por defecto, y deberías salir de ese paradigma cuando sientas que deseas manejar una acción en muchos reductores.

Más información​

Documentación

Debates

¿Cómo puedo representar "efectos secundarios" como llamadas AJAX? ¿Por qué necesitamos "creadores de acciones", "thunks" y "middleware" para comportamiento asíncrono?​

Este es un tema extenso y complejo, con diversas opiniones sobre cómo organizar el código y qué enfoques utilizar.

Cualquier aplicación web significativa necesita ejecutar lógica compleja, generalmente incluyendo trabajo asíncrono como realizar peticiones AJAX. Ese código ya no es puramente función de sus entradas, y las interacciones con el mundo exterior se conocen como "efectos secundarios".

Redux está inspirado en la programación funcional y, por defecto, no tiene espacio para ejecutar efectos secundarios. En particular, las funciones reductoras deben ser siempre funciones puras de (state, action) => newState. Sin embargo, el middleware de Redux permite interceptar acciones despachadas y añadir comportamiento complejo alrededor de ellas, incluyendo efectos secundarios.

En general, Redux sugiere que el código con efectos secundarios forme parte del proceso de creación de acciones. Aunque esta lógica puede ejecutarse dentro de un componente de UI, generalmente tiene sentido extraerla a una función reutilizable para que la misma lógica pueda llamarse desde múltiples lugares; es decir, un creador de acciones.

La forma más simple y común es añadir el middleware Redux Thunk que permite escribir creadores de acciones con lógica asíncrona compleja. Otro método ampliamente usado es Redux Saga que permite escribir código de apariencia más síncrona usando generadores, actuando como "hilos en segundo plano" en aplicaciones Redux. Otro enfoque es Redux Loop, que invierte el proceso permitiendo que tus reductores declaren efectos secundarios en respuesta a cambios de estado. Más allá de esto, existen muchas otras librerías desarrolladas por la comunidad, cada una con su propia visión sobre cómo gestionar efectos secundarios.

Más información​

Documentación

Artículos

Debates

¿Qué middleware asíncrono debería usar? ¿Cómo decidir entre thunks, sagas, observables u otras opciones?​

Existen muchos middlewares para efectos secundarios/asíncronos, pero los más utilizados son redux-thunk, redux-saga y redux-observable. Son herramientas diferentes, con distintas fortalezas, debilidades y casos de uso.

Como regla general:

  • Los thunks son ideales para lógica síncrona compleja (especialmente código que necesita acceder a todo el estado de Redux) y lógica asíncrona simple (como llamadas AJAX básicas). Con el uso de async/await, también pueden ser adecuados para lógica más compleja basada en promesas.

  • Las sagas son mejores para lógica asíncrona compleja y comportamientos desacoplados tipo "hilo en segundo plano", especialmente si necesitas escuchar acciones despachadas (algo que no pueden hacer los thunks). Requieren familiaridad con funciones generadoras y operadores "effects" de redux-saga.

  • Los observables resuelven los mismos problemas que las sagas, pero se basan en RxJS para implementar comportamientos asíncronos. Requieren familiaridad con la API de RxJS.

Recomendamos que la mayoría de usuarios de Redux comiencen con thunks, y añadan una librería adicional como sagas u observables solo si su aplicación requiere manejar lógica asíncrona más compleja.

Dado que sagas y observables cubren el mismo caso de uso, normalmente una aplicación usaría uno u otro, pero no ambos. Sin embargo, es perfectamente válido usar thunks junto con sagas u observables, ya que resuelven problemas diferentes.

Artículos

Debates

¿Debo enviar múltiples acciones consecutivas desde un mismo creador de acciones?​

No existe una regla específica sobre cómo estructurar tus acciones. Usar middleware asíncrono como Redux Thunk permite escenarios como enviar múltiples acciones relacionadas pero distintas consecutivamente, despachar acciones que representen el progreso de una solicitud AJAX, enviar acciones condicionalmente según el estado, o incluso despachar una acción y verificar inmediatamente el estado actualizado.

En general, evalúa si estas acciones están relacionadas pero son independientes, o si realmente deberían representarse como una única acción. Haz lo que tenga sentido en tu situación, pero busca equilibrar la legibilidad de los reducers con la claridad del registro de acciones. Por ejemplo, una acción que incluya todo el nuevo árbol de estado haría tu reducer de una sola línea, pero la desventaja es que perderías el historial del por qué ocurren los cambios, dificultando la depuración. Por otro lado, si emites acciones en bucle para mantenerlas granulares, es señal de que quizá necesites un nuevo tipo de acción manejado de forma diferente.

Intenta evitar despachar múltiples veces de forma síncrona y consecutiva en situaciones sensibles al rendimiento. Existen complementos y enfoques que permiten agrupar despachos.

Más información​

Documentación

Artículos

Debates