It's OK/NOT OK to subscribe in Angular

My modern Angular course: angularstart.com/
When coding reactively and declaratively in Angular with RxJS, it's best to avoid subscribing... but why? and when is it OK to break the "rules"?
Previous video: • My NEW default for sta...
More on declarative code: • What most devs don't g...
Get weekly content and tips exclusive to my newsletter: mobirony.ck.page/4a331b9076
0:00 Introduction
1:06 Upside of Declarative
2:06 Downside of Subscribe
3:21 When can you subscribe?
4:43 When to avoid subscribes?
5:00 Breaking the rules
Learn Angular with Ionic: ionicstart.com
#angular #rxjs
- More tutorials: eliteionic.com
- Follow me on Twitter: / joshuamorony

Пікірлер: 52

  • @JoshuaMorony
    @JoshuaMorony11 ай бұрын

    I've got more exclusive content going out to the mailing list tomorrow: mobirony.ck.page/4a331b9076

  • @snivels
    @snivels11 ай бұрын

    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.

  • @yuliyy__

    @yuliyy__

    11 ай бұрын

    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.

  • @cocoscacao6102

    @cocoscacao6102

    11 ай бұрын

    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

  • @abdulnafay72

    @abdulnafay72

    11 ай бұрын

    Agreed

  • @JoshuaMorony

    @JoshuaMorony

    11 ай бұрын

    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.

  • @nickolaizein7465

    @nickolaizein7465

    10 ай бұрын

    @@JoshuaMorony can you please put links in the description ? Thanks!

  • @JosimarBezerra-fx8wb
    @JosimarBezerra-fx8wb11 ай бұрын

    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.

  • @julienwickramatunga7338
    @julienwickramatunga733811 ай бұрын

    Enlightening! Nice examples given and you also made a strong point about your pragmatic approach, hats off to you!

  • @MattBodman
    @MattBodman11 ай бұрын

    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

  • @DavidWeiss2
    @DavidWeiss211 ай бұрын

    Thank you for the great content!

  • @ahammadalipk
    @ahammadalipk11 ай бұрын

    This will clearly give you an idea on what is the difference between action stream and data stream.

  • @exsitewebsolution6803
    @exsitewebsolution680311 ай бұрын

    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

  • @glimpsee7941
    @glimpsee794111 ай бұрын

    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.

  • @JoshuaMorony

    @JoshuaMorony

    11 ай бұрын

    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.

  • @briancastroTI
    @briancastroTI11 ай бұрын

    Great video!! thanks a lot :D

  • @billy8461
    @billy846111 ай бұрын

    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

  • @mfpears
    @mfpears11 ай бұрын

    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.

  • @JoshuaMorony

    @JoshuaMorony

    11 ай бұрын

    Yeah sure I'd love to read it - is a draft available now or something?

  • @mfpears

    @mfpears

    11 ай бұрын

    @@JoshuaMorony not yet. I'll let you know. I have 2 paragraphs written so far...

  • @enverusta7811
    @enverusta781111 ай бұрын

    Which tools are you using for editing and making animations?

  • @romarioputra3775
    @romarioputra37757 ай бұрын

    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?

  • @JoboyJordan
    @JoboyJordan11 ай бұрын

    Our favorite topic...

  • @karamuto1565
    @karamuto156511 ай бұрын

    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?

  • @JoshuaMorony

    @JoshuaMorony

    11 ай бұрын

    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.

  • @karamuto1565

    @karamuto1565

    11 ай бұрын

    @@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 )

  • @ytamb01
    @ytamb0111 ай бұрын

    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?

  • @JoshuaMorony

    @JoshuaMorony

    11 ай бұрын

    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)

  • @ytamb01

    @ytamb01

    11 ай бұрын

    @@JoshuaMorony Thanks very much.

  • @claudiuciprianbetiuc3985
    @claudiuciprianbetiuc398511 ай бұрын

    Hi, Joshua! I am curious about the pattern your are using for making POST requests without manually subscribing.

  • @JoshuaMorony

    @JoshuaMorony

    11 ай бұрын

    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.

  • @claudiuciprianbetiuc3985

    @claudiuciprianbetiuc3985

    11 ай бұрын

    @@JoshuaMorony , thanks for your reply!

  • @nomoredarts8918
    @nomoredarts89184 ай бұрын

    Are there any code examples I can download and run, follow along the video

  • @lucasgiunta8874
    @lucasgiunta887411 ай бұрын

    Why to not just toSignal from your observable and display them to your template instead to use kind of redux pattern with manual sub?

  • @JoshuaMorony

    @JoshuaMorony

    11 ай бұрын

    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.

  • @user-dh8td8sy4x

    @user-dh8td8sy4x

    9 ай бұрын

    @@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)

  • @JoshuaMorony

    @JoshuaMorony

    9 ай бұрын

    ​@@user-dh8td8sy4x 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

  • @timburstefan
    @timburstefan11 ай бұрын

    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?

  • @JoshuaMorony

    @JoshuaMorony

    11 ай бұрын

    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.

  • @timburstefan

    @timburstefan

    11 ай бұрын

    @@JoshuaMorony Thanks for the tip.

  • @lukassefcik9623
    @lukassefcik962311 ай бұрын

    What is the theme you are using?

  • @JoshuaMorony

    @JoshuaMorony

    11 ай бұрын

    Gruvbox

  • @lukassefcik9623

    @lukassefcik9623

    11 ай бұрын

    @@JoshuaMorony That's what I thought but thanks for confirm.

  • @pawello94lech
    @pawello94lech11 ай бұрын

    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 ?

  • @JoshuaMorony

    @JoshuaMorony

    11 ай бұрын

    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.

  • @darkogele
    @darkogele11 ай бұрын

    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 ..

  • @aravindmuthu5748
    @aravindmuthu574811 ай бұрын

    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

  • @g-luu

    @g-luu

    11 ай бұрын

    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.

  • @JoshuaMorony

    @JoshuaMorony

    11 ай бұрын

    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.