Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

338
Views
¿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 answers
Answer question

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 Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!