⚡ Cómo no volver a repetir los mismos errores de RxJs⚡

Recuerde: .pipe () no es .subscribe ()!

Este artículo está dirigido a los principiantes que intentan aumentar sus conocimientos de RxJ, pero también puede ser una actualización rápida o una referencia para mostrar a los principiantes para los desarrolladores más experimentados.

¡Hoy vamos a ser breves y directos al grano!

Actualmente estoy trabajando en una organización bastante grande, bastantes equipos y proyectos (más de 40 SPA) que están en proceso de migración a Angular y, por lo tanto, también a RxJ.

Esto representa una gran oportunidad para ponerse en contacto con las partes confusas de los RxJ que pueden ser fáciles de olvidar una vez que uno domina las API y se centra en la implementación de las funciones.

La función ".subscribe ()"

Los RxJs observables representan una "receta" de lo que queremos que suceda. Es declarativo, lo que significa que todas las operaciones y transformaciones se especifican en su totalidad desde el principio.

Un ejemplo de una corriente observable podría verse así ...

Este flujo observable de RxJ no hará literalmente nada por sí mismo. Para ejecutarlo, ¡tenemos que suscribirnos a él en algún lugar de nuestra base de código!

En el ejemplo anterior, proporcionamos un controlador solo para los valores emitidos por el observable. La función de suscripción en sí misma acepta hasta tres argumentos diferentes para manejar el siguiente valor, error o evento completo .

Además de eso, también podríamos pasar un objeto con las propiedades enumeradas anteriormente. Tal objeto es una implementación de la Observerinterfaz. La ventaja del observador es que no tenemos que proporcionar implementación o al menos un nullmarcador de posición para los controladores que no nos interesan.

Considere el siguiente ejemplo ...

En el código anterior, estamos pasando un objeto literal que contiene solo un manejador completo, los valores normales serán ignorados y los errores aparecerán en la pila.

Y en este ejemplo, pasamos el controlador del siguiente error y lo completamos como argumentos directos de la función de suscripción. Todos los manejadores no implementados deben pasarse como nulos o indefinidos hasta que lleguemos al argumento que nos interesa.

Como podemos ver, el estilo de implementación de argumentos en línea de una .subscribe()llamada a función es posicional.

En mi experiencia, el estilo de argumentos en línea es el más común en varios proyectos y organizaciones.

Desafortunadamente, muchas veces podemos encontrar una implementación como la siguiente ...

El ejemplo anterior contiene controladores redundantes para ambos nexty errorcontroladores que no hacen exactamente nada y podrían haber sido reemplazados por null.

¡Incluso mejor sería pasar el objeto observador con la completeimplementación del controlador, omitiendo otros controladores por completo!

El ".pipe ()" y los operadores

Como los principiantes están acostumbrados a proporcionar tres argumentos para suscribirse, a menudo intentan implementar un patrón similar cuando usan operadores similares en la cadena de tuberías.

Los operadores RxJ, que a menudo se confunden con los .subscribe()controladores, son catchErrory finalize. Ambos también tienen un propósito similar, la única diferencia es que se usan en el contexto de la tubería en lugar de la suscripción.

En caso de que quisiéramos reaccionar ante el evento completo de cada suscripción del flujo observable RxJs, podríamos implementar el finalizeoperador como parte del flujo observable en sí.

De esa manera, no tenemos que depender de los desarrolladores para implementar controladores completos en cada una de las llamadas .subscribe (). Recuerde, la secuencia observable se puede suscribir a más de una vez.

Esto nos lleva al patrón final y posiblemente más problemático que podemos encontrar al explorar varias bases de código: operadores redundantes agregados al intentar seguir el patrón .subscribe () en el contexto .pipe ().

Además, podríamos encontrarnos con su primo aún más detallado ...

Observe que hemos progresado desde la línea única original hasta las nueve líneas completas de código que tenemos que leer y comprender cuando queremos corregir un error o agregar una nueva característica.

Las cosas pueden volverse aún más complejas cuando se combinan con tipos genéricos de TypeScript más complejos, lo que puede hacer que todo el bloque de código sea aún más misterioso (y por lo tanto, perder más tiempo).

Recapitulación

  1. El .subscribe()método acepta tanto el objeto observador como los controladores en línea.
  2. El objeto observador representa la forma más versátil y concisa de suscribirse a un flujo observable.
  3. En caso de que queramos ir con los argumentos en línea suscribirse ( next, error, complete) podemos proporcionar nullen lugar de un controlador que no es necesario.
  4. Debemos asegurarnos de no intentar repetir el .subscribe()patrón cuando trabajamos con .pipe()operadores y.
  5. ¡Siempre esfuércese por mantener el código lo más simple posible y elimine las redundancias innecesarias!

¡Eso es! ✨

Espero que haya disfrutado de este artículo y ahora comprenda mejor cómo suscribirse a observables de RxJ con una implementación limpia y concisa.

Apoye esta guía con su ??? usar el botón de aplaudir y ayudar a que se extienda a una audiencia más amplia? Además, no dude en enviarme un ping si tiene alguna pregunta utilizando las respuestas del artículo o los mensajes directos de Twitter @tomastrajan.

Y nunca lo olvides, el futuro es brillante ¿ Comenzar un proyecto angular? ¡Eche un vistazo a Angular NgRx Material Starter!

Si ha llegado hasta aquí, no dude en consultar algunos de mis otros artículos sobre el desarrollo de software Angular y frontend en general ...

? ‍? ️ Los 7 consejos profesionales para ser productivo con CLI angular y esquemas?

Una g ular Esquemas es una herramienta de flujo de trabajo para la Web actual - introducción articlehac oficial kernoon.com   La mejor manera de Baja RxJS observable en las aplicaciones angular!

Hay muchas formas diferentes de manejar las suscripciones RxJS en aplicaciones Angular y vamos a explorar su… blog.angularindepth.com Guía total para la inyección de dependencia Angular 6+ - proporcionada en vs proveedores: []?

L et de aprender cuándo y cómo utilizar mejor mecanismo de nueva angular 6+ inyección de dependencia con la nueva sintaxis providedIn para hacer ... m edium.com La última respuesta a la muy común angular Pregunta: suscribirse () vs | tubería asíncrona

La mayoría de las bibliotecas populares de administración de estado de Angular, como NgRx, exponen el estado de la aplicación en forma de flujo de… blog.angularindepth.com