RxJesus gave his life for us.

I find it's just so good once you learn and understand it, that it hurts to go back. Boiling data streams down to contained pipes of operators frees up mental bandwidth, and Angular allowing us to subscribe in the template and not need to worry about unsubscribing removes minimizes one of the major pain-points of RxJS. It's not perfect, but it's a nice mental model imo.

100% agree

I see this concern "A code should fit its purpose, be understandable and easy to maintain" as related to a choice between imperative and declarative code, not as something secondary to it. Imperative style code is fine, but I would argue declarative code is generally more understandable and easier to maintain BUT that comes with the pre-requisite of learning/understanding and following the declarative mental model. Most (all?) devs start on an imperative model, so it's by default the more "obvious" approach, but imo that's only because of familiarity. Getting everyone on board with a declarative approach is certainly no small investment, but I think does lead to more stable/understandable/maintainable code.

Exactly, can't agree more. Let's scrap this idea that declarative is always best.

@@JoshuaMorony That observation of a historical progression of a developer from imperative to declarative programming is spot on! Also, can't wait for more videos about upcoming changes in Angular :) 1. With respect to declarative / imperative it might also depends on what level the programming process is coming on. You might need to implement some specific logic from scratch and there you use imperative code --- but you abstract it in a separate self-contained function that you then use elsewhere declaratively. 2. Sometimes there are also operators that seem declarative but can be quite limited -- a forEach method for JS arrays being an example. Oftentimes a simple for -of loop is better, since you can break the iteration, while forEach will always run through. 3. In the end, it's fine to prefer a certain coding style - it's just important that preference does not become too ossified. I prefer the declarative style - but if there is a rare situation where an imperative solution is obviously better, I won't force the declarative one for the sake of preference :)

Sadly, but I usually see more errors are made in imperative style than in declarative one. This means that maybe RxJs is harder to understand but it eventually it gives us less error prone solutions. But I like the signals anyway because they stay in the middle between plain variables and observables. They make Angular more flexible to use

@@JoshuaMorony Totally agree!

Yes this is good advice - or generally just sticking with whatever it is you are currently doing and waiting probably like a year. It's all backwards compatible so existing things will still work anyway, and then after everyone is done fighting about everything you can just adopt whatever best patterns emerge (...or just stick with what you're doing in the end!)

Effects run once initially (which you can trigger either by having them in the constructor or by initialising a class member) and then again any time any of the signals they depend on change

@@JoshuaMorony does your init effect make sense at all? As it doesn't depend on a signal at all? shouldn't it be in a constructor?

@@chaos_monster it could be, I'm playing with ideas here - putting things in the constructor might be where we end up going, but it's also generally a good idea not to do "work" in the constructor so maybe an init effect like this is a good idea for running code on init - not sure yet!

It's a private variable. I am not really a big fan of it. I much rather use public and private prefix

One thing I like about this approach vs public/private is that I often want to do something like .asObservable() for the public one, but that means it needs to come after the private one. But the default ESLint rules don't like you declaring private members before public members, so this is a nice way around that and it's also technically a stronger enforcer of private-ness as it enforces it at runtime not just compile time (not really a big deal for me though)

@@JoshuaMorony Thanks Josh for your detailed explanation, I now understand your intention. Thanks for making such great videos, they all help 🙏👍🏻

Not really imo, I think NgRx is solving a different problem - we will probably see a signal based NgRx (not sure if that will be the default or if there will be signal and RxJS based versions). I know some toying around has already been done with this.

It does, the redundant save could be avoided if you wanted to

Yes I agree it's a totally different mental model that would need to be learned, and it's not easy

Totally agree. But I like signals too because they offer sth like "middle" path

I might be missing the point of your comment, but the computed does more or less behave the same as the public observable (with one technical difference being that a signal will only notify things that depend on it when the value *changes*, with an observable you could also get emission of a new value even if that value was the same as the previous value). If some other computed signal uses the public computed signal from the service or if its used in an effect, or a template then it will react to the signal in the service changing.

Yes, as long as the employees$ stream is subscribed to from somewhere (which it will be because that data will be consumed by the app to display a list)

@@JoshuaMorony I think you need it to be like this tap((employees) => this.myApiService.save(employee).subscribe()). I don't think only subscribing to employee$ will be enough

It's the private field syntax, functionally it makes the field private but also has the side benefit of what I think is a nice naming convention for a public/private version of the same thing

It's actually official JavaScript syntax for private fields in classes

​@@nyashachiroro2531 I learn something every day. Thank you Nyasha. Since I'm more familiar with Typescript, when something is private. I just simply use the private access modifier keyword.

@@madeOfClay99 You're welcome

I would say it is something you need to be careful of - this is not a pattern I use personally, but generally it is used in conjunction with HTTP requests to get the value without having to subscribe, so ideally there is just an observable that emits one value (but even with just a HTTP request that emits one value this could still cause problems).

putting the # as a prefix makes the variable private

Yes as Yuri pointed out its the private field syntax, but mostly the reason I do this is because it allows me use the same name for a public/private version of the same thing

Not to mention debugging when you have more complex stuff. But hype is hype I guess...

I'm team NgRx Component Store

Agreed!

​@@JoshuaMorony Doesn't NgRx have too big bolderplate ?

@@magmarrex5939 If you use global store for everything - perhaps

I disagree on it being overkill - RxJS is what enables declarative code in Angular when dealing with async situations. Certainly you can write imperative code if that is what you prefer, and many (most?) people do, but I'm yet to see a declarative (or mostly declarative at least) alternative without RxJS.

Isn't if you see client as set of possibilities (that includes different states) that are attached to request - most probably you never utilised all of them intentionally (like most of us) but they are here and sometimes needed. One of this possibly in use is using switchmap attached to some event that cancels another request.

It's just an off the cuff example and I had saving to local storage in mind, but if you wanted to optimise you could just move the tap operator up so that it sends the add/remove action to the server instead of sending the list of data

Not gonna lie, it took me some seconds to realise what's going in there and it's not the best

If you add the tap before the scan you should be able to just send the "add/remove" action off to the API, and then the API could handle inserting/removing just that one bit of data