Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

346
Vistas
¿Por qué necesitamos devolver un flujo en lugar de enviar directamente un valor?

En el espacio de trabajo, mis colegas me dijeron que debo, en lugar de escribir esto

 import store from './store.ts' // Epic code ... mergeMap(data => { store.dispatch(someActionCreator(data)) return EMPTY }) ...

debería escribir algo como esto

 // Epic code ... mergeMap(data => { return of(someActionCreator(data)) }) ...

Sé que todas las acciones que están escritas en el operador rxjs se envolverán automáticamente en la función de envío y se enviarán automáticamente, pero ¿por qué es malo enviar todas las acciones como en el primer ejemplo?

Sí, no devolveremos ningún flujo $, pero si es una última iteración en secuencia, ¿realmente necesitamos devolver este flujo $ en lugar de enviarlo manualmente?

about 4 years ago · Juan Pablo Isaza
1 Respuestas
Responde la pregunta

0

Se considera una buena práctica no causar "efectos secundarios" en la mayoría de los operadores. Los efectos secundarios se pueden describir como declaraciones que modifican/mutan el estado en algún lugar "fuera" de la cadena del Operador.

Con la llamada de dispatch , provocas directamente la mutación de estado, lo que puede considerarse un efecto secundario.

Hay muchas opiniones de por qué se deben evitar los efectos secundarios. Puedo citar algunos:

  • Pureza: los operadores siempre deben producir la misma salida para la misma entrada, lo que incluye cambios en el estado exterior. Al mantener los operadores puros, se pueden realizar pruebas unitarias adecuadas y puede garantizar un comportamiento coherente en todos los usos del operador.
  • Reutilización: los operadores deben diseñarse de manera que, en principio, puedan extraerse y reutilizarse en otro lugar. Esto significa que no deben tener dependencias externas como la tienda directamente en su operador.
  • Convención: los operadores deben considerarse una colección de funciones que modifican uno o varios flujos de datos entrantes. Cualquier "reacción" a los resultados de esta manipulación de transmisión debe realizarse en "suscribirse". Esta es una convención que ayuda a que los Observables se comporten consistentemente. Dicho de otra manera: cuando alguien se suscribe a su Observable, no debería esperar efectos secundarios. En el caso de redux, ese "alguien" sería el marco.
  • Paradigma declarativo: los operadores deben describir principalmente la relación entre la entrada y la salida y no incluir "instrucciones" o declaraciones, como "haz esto, luego haz aquello". Ese es un paradigma que se considera que reduce los errores en general porque elimina las dependencias del estado subyacente del sistema.

Por cierto, el origen de todo el patrón de operador es la programación funcional, donde técnicamente no sería posible una llamada como la que estás describiendo.

Así que creo que la respuesta a su pregunta se basa principalmente en opiniones. Técnicamente, creo que no cambiará nada en su caso de uso. Además, los puntos mencionados anteriormente deben tomarse con pinzas, porque siempre causará efectos secundarios en algún lugar si se suscribe, por ejemplo, a una API HTTP en mergeMap .

about 4 years ago · Juan Pablo Isaza Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda