Why you should care about DECLARATIVE programming 

I haven't performed or seen any particular performance comparison between an imperative and reactive approach like this, but I assume any performance difference would be negligible (would be interested to see any resources anyone has on this though).

Thanks for the comment! I intentionally chose two very similar examples to try to highlight the difference I'm talking about, and it's a kind of distinction that is very particular to RxJS. It is a common view in RxJS that declarative/reactive programming ends when you subscribe. Without subscribe, the source of the observable is connected (unbroken) to its sink in the template. With subscribe, this stream is broken and I then have to manually control how to handle the data I pull out of the stream and then supply it to the template. That is the distinction I am making in the video between what I am calling imperative and declarative. But that's also just my opinion in the end!

Yeah, when he showed his "imperative" example, that looked mostly declarative to me. I associate imperative programming with lots of basic programming concepts like loops, if statements, and mutable state. Declarative programming, as I understand it, hides this from the reader and focuses on WHAT you want done, rather than what the computer will do to accomplish it, allowing the reader to understand what is going on at a higher level of abstraction, rather than having to think about state. Both examples are declarative in my opinion. The second one makes better use of a reactive programming library (I'm not familiar with this one... it's pretty cool). That's just how it looks to me.

I think you should take a bit more time understanding RxJs instead of relying on signals, yes signals will take care of 90% of your needs, but RxJs and its operators are nothing to sneeze at when it comes to utility and overall power. Knowing how to utilize RxJs in those 10% of hair-raising cases will only be possible if you've used RxJs for a long time, which you won't be if you move to signals.

No one in the world would expect that a react coder will understand angular. They like that jsx weirdness so much that they will never appreciate the simplicity of angular.

@@cipherxen2 I do not think so. I understand angular, most of my coleagues know angular and most of us can learn any frontend framework. Imho a Little bit judgemental commet from you.

You can use the startWith operator to immediately emit a value, and if you have debounce further up the chain of operators it will still debounce other values coming through the stream

Would be great to hear your thoughts further on this if you felt like sharing/elaborating (e.g. are there any particular changes you'd like to see in ReactiveForms?) :)

@@JoshuaMorony An example would be a complex form with control cross-dependencies and dynamic validators - such as: control B is disabled when control A has value of x, or - control C is not required but when control A or B have a certain value, the value of C has to be a number between x and y. Etc. If, in order to achieve that, you need to explicitly subscribe to specific controls or use .setValue() or .updateValueAndValidity() or re-assign Validators in your code - it means the api is imperative and not declarative. With declarative api, you should be able to provide a configuration object with all those conditional behaviors described as properties and callbacks. I think this is what formly and some other packages do. There is currently also a poor connection of the api with the template. You are scolded by console warnings when you use "disabled" attribute, "required" is ignored I think. Yes, a lot to be wished for :) I hope I clarified. :)

@@aram5642 Fantastic! Thanks for sharing your insight

You can make a judgement call on not unsubbing from things like HTTP requests - they emit once and then complete so it's generally not going to be an issue. But if you manually created the subscription, Angular doesn't handle unsubscribing for you and it is possible for it to cause problems (i.e. sub to http.get, component is destroyed but subscription still lingering, subscription completes after component has already been destroyed which can cause unexpected behaviour/errors). I prefer to just have an unsub strategy for every manual subscription that is created (which generally is very few anyway)

The declarative approach still exists outside of Angular and observables. Even with observables (and without the async pipe) you can still be declarative, it's just important that you only manually subscribe "at the end" - e.g. how the async pipe for Angular subscribes when you are displaying it in the template - nothing else is being done with the data in the app at that point. What you want to avoid is subscribing to pull a value out of a stream and the imperatively set that somewhere (e.g. on a class member) and then do something else with that value.

@@JoshuaMorony I see. Thanks for the explanation. In other words, declarative is basically letting rxjs do all the work as opposed to some of the work

That's a reason not to use it Code is meant to be easy to read

A valid point

I think you don't need to unsub HttpRequest, that's done automatically by Angular