Is complex RxJS still useful with Angular signals? 

will the course cover how to test?

@@alissonts6574 no, testing isn't covered in this course (the source code for the first two example apps do have tests if you want to check them out though: github.com/joshuamorony/angularstart-quicklists github.com/joshuamorony/angularstart-giflist

Thanks! And most of my diagrams are done in excalidraw (which gives it that hand drawn look) - some stuff (arrows and such) are also sometimes added when editing the video

It's somewhat true

Yes this is generally a good way to think of it - signals (specifically WritableSignals) and BehaviorSubjects fill a similar role, and whenever you set a signal or next a subject you are performing an imperative action - a WritableSignal or a BehaviorSubject are inherently not declarative because they can be imperatively changed after their declaration. On the other hand, derived computeds/observables are inherently declarative because their value can only be derived never imperative set, and you can see that computation up front in the declaration for deriving that value.

I saw it now, small mobile screen so I missed the destroy method

There aren't really any pros/cons - a subscribe, or a tap + subscribe can achieve effectively the same thing. But imo if what you are doing is pulling a value out of a stream then just a subscribe is the more direct/obvious way to do that.

Ngrx: signals for selectors, observables for effects

This would be a more declarative approach - all the state would be derived from the source streams. But the "imperative bridge" does not solve the sole purpose of getting values from RxJS to Signals, it also serves as an area where all state can be accessed/set imperatively which simplifies things a great deal (e.g. some source emits and then I react to that by accessing whatever other state I need, rather than having to have that value incorporated into the stream in some way)

@@JoshuaMorony Yeah, that makes sense. It probably still could be done declaratively though, but maybe for simplicity and readability this is nicer. Would be interesting to see this example in an all declarative way using signals.

The big thing that RxJS provides is the ability to deal with asynchronous reactivity, as in if some thing B reacts to A changing, but some time needs to pass before B can be set (e.g. because the value of A needs to be used in an HTTP request to set B). But aside from that, suppose we had to async stuff to worry about, signals are also just kind of awkward to represent events. Let's say you have some kind of source that is a signal instead of a subject, the signal will not notify anything unless it has actually changed, so you can only really sue it to represent "actions" if the data being set into the signal is different every time (which is especially awkward if there is no payload related to the event)

I've barely used materialize so haven't given it much thought, maybe I should give it a proper try but I feel like it would be more awkward to handle (though it would have the benefit of keeping all of the imperative stuff just in the subscribe/reducer set rather than nexting the error stream imperatively from the catchError). As for BehaviorSubject, I feel like Subject fits the concept better as I am trying to represent events and want to trigger an initial event, rather than storing state for the sake of essentially simulating a first event.

@@JoshuaMorony Thanks for answering. I agree and mostly do it the same way. Was just curious if you considered those alternate approaches.

The reason not to use BehaviorSubjects is because I am not using them to store state, that is the role of the signals - startWith in cases where I need it is more just a way to trigger an initial event/action automatically

signal.mutate() will cease to exist soon, but API wise I do prefer working with immutable data so I probably would do it anyway even if mutate was technically more efficient

Signal.mutate() has been removed in V17-RC0

Most of the RxJS stuff will be unchanged in 17, but likely over time we will see observable based APIs in Angular being replaced with signal ones and RxJS not being so much of a dependency for Angular. It doesn't mean RxJS can't/won't be used in Angular, just that it probably won't be a required part of the experience.

@@JoshuaMorony That's the best thing that could happen to Angular, for most beginner devs especially the ones with no Java or OOP experience, the unintuitiveness of Angular and the complexity of Rxjs has been the huge blocker to learn the framework. Now that a new state management system has been implemented in-house will get rid of all the unwanted "learning curve" that Angular has been infamous for

@@JoshuaMorony Thank you for clarification :)

It clicks more as time goes on (although I definitely don't "fully" understand RxJS) - it wasn't really until I became a bit obsessed with the benefits of declarative code that I really started understanding the more fundamental ideas, and trying to do everything in a declarative way helped pushed my understanding. I think if you appreciate the benefits of declarative code your RxJS knowledge will definitely get there eventually.

The data is only stored in the signal - the bottleneck here would likely be the DOM before anything else, so some kind of handling should be added at some point in case the user wants to scroll through 100 pages or something without switching subreddits. I think virtual scroll would be a bit tricky here due to the different sizes/dimensions of the videos, but a simple solution would probably be to just reset the data at some point (say after 500 have been loaded remove the first 250 or something like that)

I sort of have some videos like that - this one sort of covers the transition: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-aCgDs8Nv-jo.html and this one covers the general workflow I use: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-P5QPacz2-ao.html but I don't have a full from scratch style configuration video

Yes you can see at 4:23 an example of errors being set into the state signal - and yes, this course is based around these sorts of ideas

I don't have any actual stats handy but I'm pretty sure most Angular apps aren't using SSR - this particular app was also originally a mobile app (as in built natively with a web view) so SSR isn't an option there in any case. But yes, if you were doing all this on the server then our poor expand operator would miss out on the action.

@@JoshuaMorony - Yeah, IMHO that is the problem with Angular in the last few years... it didn't prioritize the server, which is the direction of every other framework. But because of that, I sometimes wonder why use observables when your data doesn't change.. just use promises... but I do appreciate declarative rxjs

@@jonathangamble it'll be interesting to see if the Angular landscape changes at all with the improvements coming for SSR - but yes I generally agree, observables are good when you want to represent changing data declaratively. If you are dealing with pagination on the client side and want to trigger an HTTP request, observables are good/necessary here. If your pagination is controlled via SSR and going to a /page/2 route or whatever, and you don't need to combine that with any other data changing on the client side, then an observable isn't as useful because there is no changing data that needs to be reacted to. Like I consider the SvelteKit PageData approach of const { myThing } = data; to be a declarative approach - the load function determines what the data will be and you have everything you need upfront/its not going to be imperatively modified later. Unless of course you do want to imperatively modify it after the load due to some other thing changing... in which case I might want observables ;)

yes, until we get signal based component inputs/outputs we are still stuck with zonejs. But expect those to drop as a point-release soon after v17

@@LarsRyeJeppesen if so I wonder about angular material, ng zorro and so on components will work

I tend to weight DX much more heavily than performance, because generally I think that better DX will ultimately lead to developers building better apps that might end up being more performant anyway. So for me, there has to be a pretty significant/obvious reduction in performance to justify using an approach with worse DX. Happy devs build good apps is my philosophy pretty much lol

Sorry to just link to a video, but I do have my thoughts on this specifically in my "Why didn't the Angular team just use RxJS?" video: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-iA6iyoantuo.html