I think that there aren't a lot of example projects that use reactive programming (in angular, with rjxs), and when presented with examples, they are often simplified and contrived. It would be nice to be able to see, reactively, how presenting data in a table that is paginated works. Or the correct reactive way of creating a form that posts to an API. Or clicking on a user that we can edit then update with an API call. Or something as simple as clicking a button, retrieving something from an API and showing a loader, then hiding the loader and displaying results on success, or showing an error on failure. Edit: Even in the Angular reactive forms documentation, all the examples are imperative. They attach a click event to a button and then get a form value etc.
This. I've been studying angular reactive programming using rxjs for a month now and there are lack example projects with complex stuff. I've managed to get the basic crud but I hit a wall when trying to do cascading select boxes that pull data from a back-end API. I've managed to get something work in a reactive manner (still needs work) and it took me like several days to get it working through extensive research and trial and error.
Whenever you call an api, subscribe. These are different kind of subjects. Automatic showing/hiding of page loader can be achieved via service and angular's Http interceptor
Some of my recent videos have tackled some of these things - the two mentioned in the video for example. The "is this viable" video covers things like loading from an API, handling loading/error states, manual or automatic retries for failed data loads. I have a video filmed coming out next week that covers the last point you mentioned (e.g. click to go to a detail page, have that load a specific thing from an API, and then display it). Generally my videos do focus on one small example each, but I do have a lot of examples of a lot of different reactive/declarative use cases.
Awesome! I've been watching your videos on this topic for awhile and that's something I was kinda confused about, whether or not I should completely avoid subscribing to obsevable streams. Thank you for making content that really helps people ( myself included ) getting better at their craft as developers.
Joshua, Could I ask you to review a todo app that I have made? I have really tried to make it as reactive as possible and that caused me to make some interesting choices.
If you're happy for me to do a video on it I might be able to do an in-depth review on it - I can't guarantee that I'll be able to do that, but I should at least be able to give you a couple pointers either way. Feel free to drop a link to a public repo.
for my project I had a component that was calling leaflet methods so I had to subscribe. Some times its the best solution instead of looking for weird work arounds
Another great video, thanks Josh. Have you done any content on your use or preferences for Interfaces v classes? It's something that comes up in my team a bit and I'd be interested in your take. Cheers
Hi joshua, can you show this example with articles data and how it shows in html for beginners who has just about understood subscribe and has no idea of signals
As I mention in the video subscribing to a POST request is fine - but if you were incorporating the response from the POST request into your app state/displaying something in the template then you don't need to (and probably shouldn't) manually subscribe. In this case you could have the POST stream and have it subscribed with the async pipe or toSignal in some manner since you are utilising the response. If you aren't using the response and still want to avoid the manual subscribe anyway (even though you don't really need to), you could use something like an NgRX Component Store effect which will essentially manage the subscribe for you.
Really enjoyed the video. Thank you. When you do the service with a subject pattern when you have a behavousubject that emits new values when http calls are made, there isn't really a way to avoid subscribing within the service is there?
No I think subscribing probably makes sense here - if you are managing the data through nexting a subject then you are working within an imperative paradigm here so pulling data into that from an API is going to require a subscribe (as opposed to say just directly using the stream from the API and composing it in other ways). The BehaviorSubject example is basically equivalent to what I am doing here - I am setting/updating a signal, but I could also have been nexting a BehaviorSubject instead (I just think signals are the better tool for this part)
Hmm I just had a colleague today who needed to call open layers apis in response to an observable stream we have defined for it ( communication between widgets). I tried to think of a way to make it declarative, but we don't have control over the the way open layers presents it's api, so I guess it was fine to subscribe there as the data was at the end of its journey?
It's hard to know without seeing the specifics but assuming you have data coming in from an API then that would be a "source" and at least with the specific approach I am using here I would have that source represented in the service, subscribe to it, and have the reducer step to set the result into the signal.
@@JoshuaMorony yeah in this case the data comes from a service holding a combination of API data and a local state from a registered component. Meaning: Component a sends an event -> data is mapped with values from the API -> other component recieves data ( subscribe ) and calls functions from open layer in response to this inputs. ( We got no angular component exposed by open layers that we could bind to )
I really want to hear what you think about the article I'm working on right now. I am describing a way to switch from RxJS to signals without eagerly subscribing, so requests can be automatically canceled and reset. Unfortunately, it requires a utility class about 80 lines long. So I'm going to see if I can get Powell and Alex to maybe put it inside rxjs-compat directly. It might be a little weird; it is interesting; but I think it would be extremely worth it.
If the 3rd party is providing a stream that would need to subscribe to then you can use that stream as a data source (which at least in the example I am showing is then subscribed manually, but it is also possible to use that stream without subscribing early) - if by doesn't know what RxJS is you mean it supplies data with promises for example, then you can also use the RxJS from() creation operator to turn the promise into an observable stream.
Let's say I load my data initially, which will be a stream - if I just want to display that data or something derived from that data it's fine I can just toSignal and be done. But what if I also want to edit that data? So I have my edit$ source, and now I need to combine my original data stream with the edit$ source stream to make sure the edits are reflected in the stream. The same goes say if I want to use an add$ source to also add some data. This is all fine and you can manage it all with just RxJS and then use toSignal, but it becomes considerably more complicated as you need to have more knowledge of RxJS operators (especially things like scan). The reducer step to set into a signal here basically skips the requirement for the more advanced RxJS operators, and allows you to modify the state however you want.
@@JoshuaMorony in this sense of receiving data from the server and editing it later, I know that you can modify it using the scan operator and a reducer stream, but you can also create a behavior subject and "load it" with a subscription that updates the behavior subject. Do you think doing this is valid? or is it better to use scan operator? (this is in a world without signals, at my work they still use angular 11 haha)
@@RafaelPinheiro-m3o yes this is fine - it's basically the same idea as using the signals: in the context of what we have been talking about, nexting as subject and setting a signal are similar, they are both imperative actions that are putting the data back into a reactive mechanism
Within the pattern I'm showing in the video I just have form controls defined at the service level, then I can combine the valueChanges with whatever sources I need - obviously this pattern still involves manual subscribes. But otherwise, it depends what you want to do, I generally just try to think of valueChanges as a data source/stream like any other.
I switched to Blazor and all of this shit with rxjs that is way to complicated i dont have to care anymore. Angular is to complex and to chaotic compare to every other UI framework or LIb, its just shit. And im using angular for the past 5 years and this cancer boilerplate it just demotivated me to continue with this google wanna be UI. Is there chance for you to do videos on some other ui not just angular or you wanna be focused only on this framework? Thx in advance with respect sorry to tell type my frustration on angular but its just to much ..
I just want to point it out here: Rxjs is NOT Angular and vice-versa. Previously uptil Angular 15, the internal state management tool of Angular was very much unreliable, we had to bring in Rxjs for all sort of state management using it. Now with the advent of signals, and just as Joshua pointed out, the state management is decoupled from event management which eases the dependency of Rxjs in Angular. Now with the new state management in place, having rxjs seems like a blatant overkill for most applications. Sure, if you have to handle tons of events flying all over the application, then rxjs is an amazing way to streamline, but to store an api response with a button click, you don't need require any more than our good old Promise.then operator couldn't handle
Angular was meant to be reactive so to advise folks to use promises is a bad idea. Rxjs is not going anywhere as Josh example clearly demonatrates why async behaviour is best handled by rxjs and component state by signals.
From my point of view, I don't see it as overkill (but it is good that we can use signals for "state" now and RxJS for "events") - imo all apps have events flying around, otherwise they would be static web pages. I think people generally think of RxJS as managing things like web sockets or where you have things like real time stock trading data or something. But every user action or every time anything loads, these are all events and they happen constantly. The appeal of RxJS here for me isn't that I necessarily need to "coordinate" these events because they are all happening so fast, it is so that the codebase can be represented in a reactive/declarative way - without RxJS (or something in its place to handle events) it would have to be imperative. Which is fine if that's what you want, but RxJS does provide more than just event coordination.
![[LIVE] : ONE ลุมพินี 87 วันนี้!! คู่เอก "ก้องชัย vs โชคปรีชา"](http://i.ytimg.com/vi/YN6e7HVnekw/mqdefault.jpg)
I've got more exclusive content going out to the mailing list tomorrow: mobirony.ck.page/4a331b9076
I think that there aren't a lot of example projects that use reactive programming (in angular, with rjxs), and when presented with examples, they are often simplified and contrived. It would be nice to be able to see, reactively, how presenting data in a table that is paginated works. Or the correct reactive way of creating a form that posts to an API. Or clicking on a user that we can edit then update with an API call. Or something as simple as clicking a button, retrieving something from an API and showing a loader, then hiding the loader and displaying results on success, or showing an error on failure.
Edit: Even in the Angular reactive forms documentation, all the examples are imperative. They attach a click event to a button and then get a form value etc.
This. I've been studying angular reactive programming using rxjs for a month now and there are lack example projects with complex stuff. I've managed to get the basic crud but I hit a wall when trying to do cascading select boxes that pull data from a back-end API. I've managed to get something work in a reactive manner (still needs work) and it took me like several days to get it working through extensive research and trial and error.
Whenever you call an api, subscribe. These are different kind of subjects. Automatic showing/hiding of page loader can be achieved via service and angular's Http interceptor
Agreed
Some of my recent videos have tackled some of these things - the two mentioned in the video for example. The "is this viable" video covers things like loading from an API, handling loading/error states, manual or automatic retries for failed data loads. I have a video filmed coming out next week that covers the last point you mentioned (e.g. click to go to a detail page, have that load a specific thing from an API, and then display it). Generally my videos do focus on one small example each, but I do have a lot of examples of a lot of different reactive/declarative use cases.
@@JoshuaMorony can you please put links in the description ? Thanks!
Awesome! I've been watching your videos on this topic for awhile and that's something I was kinda confused about, whether or not I should completely avoid subscribing to obsevable streams. Thank you for making content that really helps people ( myself included ) getting better at their craft as developers.
This will clearly give you an idea on what is the difference between action stream and data stream.
Enlightening!
Nice examples given and you also made a strong point about your pragmatic approach, hats off to you!
Joshua, Could I ask you to review a todo app that I have made? I have really tried to make it as reactive as possible and that caused me to make some interesting choices.
If you're happy for me to do a video on it I might be able to do an in-depth review on it - I can't guarantee that I'll be able to do that, but I should at least be able to give you a couple pointers either way. Feel free to drop a link to a public repo.
Our favorite topic...
for my project I had a component that was calling leaflet methods so I had to subscribe. Some times its the best solution instead of looking for weird work arounds
Another great video, thanks Josh. Have you done any content on your use or preferences for Interfaces v classes? It's something that comes up in my team a bit and I'd be interested in your take. Cheers
Hi joshua, can you show this example with articles data and how it shows in html for beginners who has just about understood subscribe and has no idea of signals
Thank you for the great content!
what happen if I have two or more states (so i put them in different services), but both of them depend (by RxJS) on each other?
Which tools are you using for editing and making animations?
Hi, Joshua! I am curious about the pattern your are using for making POST requests without manually subscribing.
As I mention in the video subscribing to a POST request is fine - but if you were incorporating the response from the POST request into your app state/displaying something in the template then you don't need to (and probably shouldn't) manually subscribe. In this case you could have the POST stream and have it subscribed with the async pipe or toSignal in some manner since you are utilising the response. If you aren't using the response and still want to avoid the manual subscribe anyway (even though you don't really need to), you could use something like an NgRX Component Store effect which will essentially manage the subscribe for you.
@@JoshuaMorony , thanks for your reply!
Great video!! thanks a lot :D
Really enjoyed the video. Thank you. When you do the service with a subject pattern when you have a behavousubject that emits new values when http calls are made, there isn't really a way to avoid subscribing within the service is there?
No I think subscribing probably makes sense here - if you are managing the data through nexting a subject then you are working within an imperative paradigm here so pulling data into that from an API is going to require a subscribe (as opposed to say just directly using the stream from the API and composing it in other ways). The BehaviorSubject example is basically equivalent to what I am doing here - I am setting/updating a signal, but I could also have been nexting a BehaviorSubject instead (I just think signals are the better tool for this part)
@@JoshuaMorony Thanks very much.
Hmm I just had a colleague today who needed to call open layers apis in response to an observable stream we have defined for it ( communication between widgets).
I tried to think of a way to make it declarative, but we don't have control over the the way open layers presents it's api, so I guess it was fine to subscribe there as the data was at the end of its journey?
It's hard to know without seeing the specifics but assuming you have data coming in from an API then that would be a "source" and at least with the specific approach I am using here I would have that source represented in the service, subscribe to it, and have the reducer step to set the result into the signal.
@@JoshuaMorony yeah in this case the data comes from a service holding a combination of API data and a local state from a registered component.
Meaning:
Component a sends an event ->
data is mapped with values from the API -> other component recieves data ( subscribe ) and calls functions from open layer in response to this inputs.
( We got no angular component exposed by open layers that we could bind to )
I really want to hear what you think about the article I'm working on right now. I am describing a way to switch from RxJS to signals without eagerly subscribing, so requests can be automatically canceled and reset. Unfortunately, it requires a utility class about 80 lines long. So I'm going to see if I can get Powell and Alex to maybe put it inside rxjs-compat directly. It might be a little weird; it is interesting; but I think it would be extremely worth it.
Yeah sure I'd love to read it - is a draft available now or something?
@@JoshuaMorony not yet. I'll let you know. I have 2 paragraphs written so far...
Are there any code examples I can download and run, follow along the video
Feels like the reducer layer in Cycle.js
But what if I have a 3rd party library that doesn't know what rxjs is and i need to subscribe in order to get the necessary data for that library?
If the 3rd party is providing a stream that would need to subscribe to then you can use that stream as a data source (which at least in the example I am showing is then subscribed manually, but it is also possible to use that stream without subscribing early) - if by doesn't know what RxJS is you mean it supplies data with promises for example, then you can also use the RxJS from() creation operator to turn the promise into an observable stream.
@@JoshuaMorony Thanks for the tip.
Why to not just toSignal from your observable and display them to your template instead to use kind of redux pattern with manual sub?
Let's say I load my data initially, which will be a stream - if I just want to display that data or something derived from that data it's fine I can just toSignal and be done. But what if I also want to edit that data? So I have my edit$ source, and now I need to combine my original data stream with the edit$ source stream to make sure the edits are reflected in the stream. The same goes say if I want to use an add$ source to also add some data. This is all fine and you can manage it all with just RxJS and then use toSignal, but it becomes considerably more complicated as you need to have more knowledge of RxJS operators (especially things like scan). The reducer step to set into a signal here basically skips the requirement for the more advanced RxJS operators, and allows you to modify the state however you want.
@@JoshuaMorony in this sense of receiving data from the server and editing it later, I know that you can modify it using the scan operator and a reducer stream, but you can also create a behavior subject and "load it" with a subscription that updates the behavior subject.
Do you think doing this is valid? or is it better to use scan operator?
(this is in a world without signals, at my work they still use angular 11 haha)
@@RafaelPinheiro-m3o yes this is fine - it's basically the same idea as using the signals: in the context of what we have been talking about, nexting as subject and setting a signal are similar, they are both imperative actions that are putting the data back into a reactive mechanism
What is the theme you are using?
Gruvbox
@@JoshuaMorony That's what I thought but thanks for confirm.
I wonder if there is any way of not manually subscribing to value changes in the forms. Do you have a nice way of doing this ?
Within the pattern I'm showing in the video I just have form controls defined at the service level, then I can combine the valueChanges with whatever sources I need - obviously this pattern still involves manual subscribes. But otherwise, it depends what you want to do, I generally just try to think of valueChanges as a data source/stream like any other.
I switched to Blazor and all of this shit with rxjs that is way to complicated i dont have to care anymore.
Angular is to complex and to chaotic compare to every other UI framework or LIb, its just shit.
And im using angular for the past 5 years and this cancer boilerplate it just demotivated me to continue with this google wanna be UI.
Is there chance for you to do videos on some other ui not just angular or you wanna be focused only on this framework?
Thx in advance with respect sorry to tell type my frustration on angular but its just to much ..
I just want to point it out here: Rxjs is NOT Angular and vice-versa. Previously uptil Angular 15, the internal state management tool of Angular was very much unreliable, we had to bring in Rxjs for all sort of state management using it. Now with the advent of signals, and just as Joshua pointed out, the state management is decoupled from event management which eases the dependency of Rxjs in Angular. Now with the new state management in place, having rxjs seems like a blatant overkill for most applications. Sure, if you have to handle tons of events flying all over the application, then rxjs is an amazing way to streamline, but to store an api response with a button click, you don't need require any more than our good old Promise.then operator couldn't handle
Angular was meant to be reactive so to advise folks to use promises is a bad idea.
Rxjs is not going anywhere as Josh example clearly demonatrates why async behaviour is best handled by rxjs and component state by signals.
From my point of view, I don't see it as overkill (but it is good that we can use signals for "state" now and RxJS for "events") - imo all apps have events flying around, otherwise they would be static web pages. I think people generally think of RxJS as managing things like web sockets or where you have things like real time stock trading data or something. But every user action or every time anything loads, these are all events and they happen constantly. The appeal of RxJS here for me isn't that I necessarily need to "coordinate" these events because they are all happening so fast, it is so that the codebase can be represented in a reactive/declarative way - without RxJS (or something in its place to handle events) it would have to be imperative. Which is fine if that's what you want, but RxJS does provide more than just event coordination.