▬ Aclaración ▬▬▬▬▬▬▬▬▬▬ Acuérdensen de hacer complete() al destroy$ para el take until !!! de esta manera vamos a cambiar el estado interno del subject para que éste se complete y no genere ningun memory leak this.destroy$.complete();
Entonces en el metodo onDestroy después de hacerle .next(true) tengo que hacer .complete()?? Gracias, y otra duda es tmbien se debe desuscribir cuando hacemos un .valueChanges en un formControl? O no es necesario.? Graciaas!!
0:17 - definición de memory leak -- Forma 1 -- 2:40 - Unsubscribe con `Subscription` 5:45 - Unsubscribe cuando existen más de un observable -- Forma 2 -- 8:00 - Unsubscribe con RxJs operador `takeUntil()` -- Forma 3 -- 11:45 - Guardar el observable en una variable de tipo observable, sin crear subscripción 12:50 - Uso de la variable asíncrona con pipe async
@gentleman Programing Tengo dos preguntas acerca de la tercer forma de implementacion : 1 - Como se manejarian los errores si es que lo hay en la parte de this.persona$ = sharingService.sharingOservable; 2 - En cuanto a perfomance entre la forma 2 y la 3 la hay?
Peeerfecto, empezamos: 1- puedes utilizar dentro del pipe, el operador catchError ! 2- aquí no quiero que pienses en performance, cualquiera de las tres son buenas opciones PERO, piensa en la capacidad de mantener y escalar el proyecto. takeUntil esta genial ! pero dependemos de acordarnos de hacer el next en el destroy, de saber en qué lugar colocarlo cuando tenemos ya algunas cadenas de operadores y de colocarlo en todas nuestras subscripciones. Ahora el pipe async… es mágico, nos obliga a pensar de forma ordenada, nos hace el unsubscribe solito, separa la lógica del resto de la app ya que está todo concentrado en un solo lugar en vez de tener partes de la lógica para el manejo de la suscripción en varios sitios. También como bien preguntaste, se pueden ir encadenando operadores de manera ordenada para ir controlando el flujo de información y en cualquier caso usar un catchError para controlar errores. Espero haberte ayudado !
@@GentlemanProgramming perfecto Alan!!!!, Muchisimas gracias por responer a las preguntas!!!!. Aunque tengo una mas, en que caso realmente deberiamos usar subcriptions y no async pipe?
@@silviocattanese546 Otra buena pregunta ! realmente todo puede hacerse con Async ;) PERO hay gente que encuentra más fácil manejar los combineLatest o cualquier merge de observables con un takeUntil. Aunque nuevamente… todo puede hacerse con async pero si que tienes que ser más ordenado y saber más del tema.
@@GentlemanProgramming Muchisimas gracias Alan por la respuesta se entendio perfectamente!. Para terminar, en algun momento tenes pensado hacer algun post sobre cual es la forma mas optima de hacer caching de llamadas a servicios para no volver a realizar las solicitudes cuando solo sea necesario.
Alan. Si mi mi coreModule que genero, está dentro de un módulo lazy que está dentro de otro módulo lazy. ¿lo declaro en el provider del módulo más cercano?. Digamos que los componentes dentro de ese módulo son los únicos que necesitan usar el servicio para comunicarse entre ellos con el estado
Declara los observables en un servicio propio del módulo que lo utilizaría para sus componentes. Si quieres compartirlo también entre módulos, hazlo en el módulo padre de los involucrados ;)
Buenas, estuvo genial el vídeo ¿en caso de necesitar hacer varias llamadas, se podría seguir haciendo con el pipe usando el combineLastest o el merge? Gracias!
Si las llamadas no dependen unas de los resultados de otras se puede usar combineLatest u otros operadores de combinación de observables. En caso de depender tiene merge o switch map. Tranquilamente se pueden encadenar la cantidad de llamadas que necesites :)
@Gentleman Programming Alan consulta, si quiero utilizar la manera corta (observable/async) del lado del TS, se podría? o si o si la manera más elegante es con el takeUntil? Saludos y gracias por todo!
¿en tu día a día usas siempre la forma 3 para el manejo de observables?. O existen casos en los que necesitas utilizar de las otras formas?. ¿Podrías dar un ejemplo?
Yo por ejemplo. Usé la tercer forma en una actividad que estoy haciendo. Pero ocupo usar los valores que trae el observable, pero... como el método getter me envía un asObservable() de mi BehaviorSubject no puedo accerder a ellos simplemente. Apenas haciendo una subscripción. Me mantiene con duda de si en ese caso, lo mejor sería usar la forma 1 o 2 en lugar de la 3
Si sigo con el método 3. Sin subscribirme, puedo añadirle un método pipe, para transformar la data y almacenarla en una variable síncrona y manipular esos datos. ¿Sería correcto?
@@danielmeza7156 como te comentaba en la comunidad, si utilizas el pipe async podrias utilizar el operador "tap" para acceder a los valores del observable en un determinado momento y guardar ese valor en alguna variable. Igualmente es mucho mejor si puedes utilizar map para transformar los valores que pasen por el observable para mostrarlos en el html ;)
Buen día, quería preguntar si tomo la tercera opción de asignarlo a un Observable, pero no solo obtengo información y la pinto en la vista, si no que ejemplo tengo una validacion de status de respuesta, mejor dicho tengo mi función normal que contiene un suscribe((data: Persona)=>{.....}), como se debe manejar con la tercera opción, agradezco la respuesta.
Hola Andrés !! podes usarlo de la siguiente manera, si además de mostrar cosas en pantalla quieres obtener un valor para guardarlo o lo que fuese, usa el pipe “TAP” ya que te permite obtener cada valor que pasa por el pipe para hacer lo que quieras y luego sigue su curso :)
Yes ! porque el post necesita de un subscribe para ejecutarse, aparte es buena práctica que manejes qué sucede cuando hay error en el mismo o te llega la data (por ejemplo mostrar un cartel de success o error) El pipe async es más que nada para http requests y cualquier otro tipo de observable que emita eventos
@@GentlemanProgramming Gracias, me gustaría también aprovechar para sacarme otra duda, con la tercera forma que explicas aunque el código se reduce mucho, no es mejor utilizar el ngOnDestroy() para desubscribirse? Creo que es lo ideal, para esto esta hecho el método ngOnDestroy
@@ArmanGO-Oficial es que ya no es necesario ! El pipe async automáticamente desubscribe el observable al destruirse el componente, fue hecho especialmente para manejar operaciones asíncronas. Otra cosa, ngOnDestroy en verdad no está hecho para desubscribir observables sino para ejecutar cualquier tipo de lógica que necesites a la hora de destruir el componente, siendo una de ellas el manejar memory leaks. Espero haberte ayudado !
@@GentlemanProgramming Gracias Gentleman tenía esta duda, una última cosa quieres ser mi Mentor? es que eres un puto Mago y me recomiendan conseguirme un Mentor y pienso que eres la ostia, el indicado. No mentiras no molesto más pero si quieres sigo molestando 😏. Pdd: es broma pero lo decía enserió jajaja, gracias de igual forma 👍🏻
Una duda. Con la segunda manera, a todos los observables que les pase el pipe(takeuntil(this.onDestroy$)) se desubscribiría? Para manejar varios observables y liberar la memoria de una cuando se destruya o tengo que hacer una variable por cada observable?
▬ Aclaración ▬▬▬▬▬▬▬▬▬▬
Acuérdensen de hacer complete() al destroy$ para el take until !!! de esta manera vamos a cambiar el estado interno del subject para que éste se complete y no genere ningun memory leak
this.destroy$.complete();
Entonces en el metodo onDestroy después de hacerle .next(true) tengo que hacer .complete()??
Gracias, y otra duda es tmbien se debe desuscribir cuando hacemos un .valueChanges en un formControl? O no es necesario.? Graciaas!!
@@andrevera3994
1- yes
2- generalmente cuando modificamos los validadores o cambiamos el valor del formControl a mano :)
Genial video, ya entendí mejor como funciona el takeUntil, me quedo claro todo
Gracias crack :)
Que bieeen !! muchas gracias por verlo :)
0:17 - definición de memory leak
-- Forma 1 --
2:40 - Unsubscribe con `Subscription`
5:45 - Unsubscribe cuando existen más de un observable
-- Forma 2 --
8:00 - Unsubscribe con RxJs operador `takeUntil()`
-- Forma 3 --
11:45 - Guardar el observable en una variable de tipo observable, sin crear subscripción
12:50 - Uso de la variable asíncrona con pipe async
Gran video hermano cada vez voy aprendiendo más saludos desde Ecuador
Muchas gracias !!!! Lo que necesites ya sabes :)
Muchas gracias bro!!! eres un crack!!
De nada Joseth ! Muchísimas gracias por el comment 😊
Gracias señor bigotes, muy buenos tips.
Buen Video bro. yo uso pipe Async y TakeUntil...
Muchas gracias Ramon, thats the way !!!
que genio !
comparto con mi compa
Muchísimas gracias Rodrigo 😍😍
mucho crack de verdad gracias
Gracias miles Fabio !
Buen video, para la Forma 2, yo suelo definir el Subject de tipo void XD
Si definimos el Subject de tipo void entonces en el onDestroy ya sólo sería necesario poner el .next() sin ningún parámetro?
@@godzito exactamente 😁
@@jemc300x muchas gracias!
Muy bueno....
Muchas gracias..... :D
En nada esta en HD, esta procesando !!
Ya lo tienen !!!!!
@gentleman Programing
Tengo dos preguntas acerca de la tercer forma de implementacion :
1 - Como se manejarian los errores si es que lo hay en la parte de this.persona$ = sharingService.sharingOservable;
2 - En cuanto a perfomance entre la forma 2 y la 3 la hay?
Peeerfecto, empezamos:
1- puedes utilizar dentro del pipe, el operador catchError !
2- aquí no quiero que pienses en performance, cualquiera de las tres son buenas opciones PERO, piensa en la capacidad de mantener y escalar el proyecto.
takeUntil esta genial ! pero dependemos de acordarnos de hacer el next en el destroy, de saber en qué lugar colocarlo cuando tenemos ya algunas cadenas de operadores y de colocarlo en todas nuestras subscripciones.
Ahora el pipe async… es mágico, nos obliga a pensar de forma ordenada, nos hace el unsubscribe solito, separa la lógica del resto de la app ya que está todo concentrado en un solo lugar en vez de tener partes de la lógica para el manejo de la suscripción en varios sitios. También como bien preguntaste, se pueden ir encadenando operadores de manera ordenada para ir controlando el flujo de información y en cualquier caso usar un catchError para controlar errores.
Espero haberte ayudado !
@@GentlemanProgramming perfecto Alan!!!!, Muchisimas gracias por responer a las preguntas!!!!. Aunque tengo una mas, en que caso realmente deberiamos usar subcriptions y no async pipe?
@@silviocattanese546 Otra buena pregunta ! realmente todo puede hacerse con Async ;)
PERO hay gente que encuentra más fácil manejar los combineLatest o cualquier merge de observables con un takeUntil. Aunque nuevamente… todo puede hacerse con async pero si que tienes que ser más ordenado y saber más del tema.
@@GentlemanProgramming Muchisimas gracias Alan por la respuesta se entendio perfectamente!.
Para terminar, en algun momento tenes pensado hacer algun post sobre cual es la forma mas optima de hacer caching de llamadas a servicios para no volver a realizar las solicitudes cuando solo sea necesario.
@@silviocattanese546 es muy posible !!! Déjame que lo anoto así lo tengo en cuenta para esta seguidilla de vídeos que estoy haciendo
Alan. Si mi mi coreModule que genero, está dentro de un módulo lazy que está dentro de otro módulo lazy. ¿lo declaro en el provider del módulo más cercano?. Digamos que los componentes dentro de ese módulo son los únicos que necesitan usar el servicio para comunicarse entre ellos con el estado
Declara los observables en un servicio propio del módulo que lo utilizaría para sus componentes. Si quieres compartirlo también entre módulos, hazlo en el módulo padre de los involucrados ;)
Buenas, estuvo genial el vídeo ¿en caso de necesitar hacer varias llamadas, se podría seguir haciendo con el pipe usando el combineLastest o el merge? Gracias!
Si las llamadas no dependen unas de los resultados de otras se puede usar combineLatest u otros operadores de combinación de observables. En caso de depender tiene merge o switch map. Tranquilamente se pueden encadenar la cantidad de llamadas que necesites :)
@Gentleman Programming Alan consulta, si quiero utilizar la manera corta (observable/async) del lado del TS, se podría? o si o si la manera más elegante es con el takeUntil?
Saludos y gracias por todo!
No es solo la más elegante, sinó también la más eficiente ! ya que hace el unsubscribe de manera automática :)
¿en tu día a día usas siempre la forma 3 para el manejo de observables?. O existen casos en los que necesitas utilizar de las otras formas?. ¿Podrías dar un ejemplo?
Yo por ejemplo. Usé la tercer forma en una actividad que estoy haciendo. Pero ocupo usar los valores que trae el observable, pero... como el método getter me envía un asObservable() de mi BehaviorSubject no puedo accerder a ellos simplemente. Apenas haciendo una subscripción. Me mantiene con duda de si en ese caso, lo mejor sería usar la forma 1 o 2 en lugar de la 3
Si sigo con el método 3. Sin subscribirme, puedo añadirle un método pipe, para transformar la data y almacenarla en una variable síncrona y manipular esos datos. ¿Sería correcto?
@@danielmeza7156 como te comentaba en la comunidad, si utilizas el pipe async podrias utilizar el operador "tap" para acceder a los valores del observable en un determinado momento y guardar ese valor en alguna variable. Igualmente es mucho mejor si puedes utilizar map para transformar los valores que pasen por el observable para mostrarlos en el html ;)
Buen día, quería preguntar si tomo la tercera opción de asignarlo a un Observable, pero no solo obtengo información y la pinto en la vista, si no que ejemplo tengo una validacion de status de respuesta, mejor dicho tengo mi función normal que contiene un suscribe((data: Persona)=>{.....}), como se debe manejar con la tercera opción, agradezco la respuesta.
Hola Andrés !! podes usarlo de la siguiente manera, si además de mostrar cosas en pantalla quieres obtener un valor para guardarlo o lo que fuese, usa el pipe “TAP” ya que te permite obtener cada valor que pasa por el pipe para hacer lo que quieras y luego sigue su curso :)
@@GentlemanProgramming Muchas gracias, voy aplicarlo
Casi el 100% de las veces no van a necesitar subscribirs...¿Que pasa con un http post? ¿Hay manera de no subcribirse a eso?
Yes ! porque el post necesita de un subscribe para ejecutarse, aparte es buena práctica que manejes qué sucede cuando hay error en el mismo o te llega la data (por ejemplo mostrar un cartel de success o error)
El pipe async es más que nada para http requests y cualquier otro tipo de observable que emita eventos
@@GentlemanProgramming Gracias 🙂
excelente :-{)
En lass peticiones por medio de HttpClient es necesario desubscribirse o ellas se desubscriben solas?....Gracias de ante mano
En las peticiones http no hay necesidad ya que al finalizar llaman al método complete() y terminan su funcionamiento :)
@@GentlemanProgramming Gracias, me gustaría también aprovechar para sacarme otra duda, con la tercera forma que explicas aunque el código se reduce mucho, no es mejor utilizar el ngOnDestroy() para desubscribirse? Creo que es lo ideal, para esto esta hecho el método ngOnDestroy
@@ArmanGO-Oficial es que ya no es necesario ! El pipe async automáticamente desubscribe el observable al destruirse el componente, fue hecho especialmente para manejar operaciones asíncronas. Otra cosa, ngOnDestroy en verdad no está hecho para desubscribir observables sino para ejecutar cualquier tipo de lógica que necesites a la hora de destruir el componente, siendo una de ellas el manejar memory leaks.
Espero haberte ayudado !
@@GentlemanProgramming Gracias Gentleman tenía esta duda, una última cosa quieres ser mi Mentor? es que eres un puto Mago y me recomiendan conseguirme un Mentor y pienso que eres la ostia, el indicado. No mentiras no molesto más pero si quieres sigo molestando 😏.
Pdd: es broma pero lo decía enserió jajaja, gracias de igual forma 👍🏻
@@ArmanGO-Oficial primero que muchas gracias !! Y te espero en Discord para discutir un poco la mentoría :)
las peticiones http con httpClient tambien es necesario hacerle un unsubscription?
Not at all ! ya tienen un complete subscription en su interior que cancela la subscription
@@GentlemanProgramming gracias
async ❤
Always and forever !!
Una duda. Con la segunda manera, a todos los observables que les pase el pipe(takeuntil(this.onDestroy$)) se desubscribiría? Para manejar varios observables y liberar la memoria de una cuando se destruya o tengo que hacer una variable por cada observable?
Exactamente, automaticamente al recibir el evento en el onDestroy va a desubsribir a todos los que lo esten escuchando
Ah está buenísimo, gracias. Justo estaba resolviedo un problema de Memory Leaks