Is complex RxJS still useful with Angular signals?

[@JoshuaMorony]

Psst, my Angular course is launching soon - don't miss the launch discount: mobirony.ck.page/4a331b9076

[@alissonts6574]

will the course cover how to test?

[@JoshuaMorony]

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

[@sakesun]

The sample code, graphics, annotation, and editing. This channel is the finest coding channel produced by the author who really care.

[@LarsRyeJeppesen]

NGRX has the sweet spot for us - it allows to expose selectors as signals. Wonderful

[@philip-rodrigues]

Your channel inspires me, I'm really curious to know how you make these slides, it looks like it was done by hand, thanks for the video

[@JoshuaMorony]

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

[@unhandledexception1948]

can't wait for the course

[@holycrimpsauce]

I’ve just had a little brain lightbulb: signal() is to computed() as Subject is to Observable. If your application is declarative, computed signals and observables only react. Whereas (writable) signals and subjects can be changed more directly. To be more declarative, lean towards computed signals and observables whenever possible.

[@e-jarod4110]

It's somewhat true

[@JoshuaMorony]

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.

[@pedrofernandes2005]

This is very nice. I was interested in seeing how you would integrate the pagination subject (when to reset,etc) but i forgot reddit api works differently

[@machiinate]

I still watch your videos even though I´m no longer writing Angular code all that often, since starting a new job been using react for the first time. I´m interested to keep following along, recently build an infinite scroll feature similar to this so far so good, React feels more like writing vanilla JS but im keen to stay in touch with the Angular ecosystem things are moving fast for as much pain RXJS can be to learn it´s very powerful.

[@TayambaMwanza]

Signals for State, Rxjs for events ✅️

[@LarsRyeJeppesen]

Ngrx: signals for selectors, observables for effects

[@vredurs]

I have a question, when you setup a subscription in the constructor, and in the subscribe, update the signal, is the subscription cancelled or unsubscribed automatically then? Or have you just omitted that to minimize the code in the example? Thanks for all the great content

[@vredurs]

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

[@bric305]

Great video as usual. I do wish though that you could explain why this solution (or part of it) using only signals would not work. The same way you explained how signals solved the diamond problem of rxjs in your other video "why angular team didn't go with rxjs?"

[@JoshuaMorony]

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)

[@supirman]

I wish I fully understood the rxjs the way you do. My app uses rxjs crudely, but has a smattering of imperative stuff built in still as I don't fully know how to do all the rxjs awesomeness you show.

[@JoshuaMorony]

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.

Why are you using signal.update() instead of signal.mutate()? Is there specific reason for that?

[@JoshuaMorony]

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

[@LarsRyeJeppesen]

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

[@shivisuper91]

Is there a specific reason to use Subject sources and not BehaviourSubject sources? Because almost always you're using startWith operator to give it an initial value anyways...?

[@JoshuaMorony]

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

[@kaischonberger97]

Beautiful code, well done. Two questions: - Did you consider to use the materialize operator to materialize errors instead of adding and extra Observable for the error? - Did you consider using a BehaviorSubject to get rid of the startsWith operator for the pagination?

[@JoshuaMorony]

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.

[@kaischonberger97]

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

[@neilfarted]

I'm not sure I understand the choices made with error handling, maybe I'm missing some context. You have an error property in the state signal that doesn't appear to be used, instead, you are handling errors with a stream (rxjs Subject). Why is this? Why have an error property in the state if you are not going to use it, and why is a stream of errors more helpful than updating the state with any errors that are caught?

[@kingpinkent]

Can you not skip the imperative bridge by using the toSignal method from rxjs-interop and wrap the observable?

[@JoshuaMorony]

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)

[@kingpinkent]

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

[@ico0z]

This approach isn't it require a lot memory keeping the gifts in an observable and in a signal again? Isn't it the same data twice in memory?

[@JoshuaMorony]

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)

[@TheXeropax]

Will Angular keep RxJS stufff in Angular 17? I'm confused a little.

[@JoshuaMorony]

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.

[@aravindmuthu5748]

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

[@TheXeropax]

@@JoshuaMorony Thank you for clarification :)

[@tarquin161234]

@@aravindmuthu5748 Well that's a shame because Angular with rxjs is simply a pleasure to use. I feel the opposite to you - I think Angular shouldn't be focusing on developers that can't be bothered to learn and instead should focus on providing a powerful tool to those who do. By the way, signals don't replace rxjs.

[@jakehockey10]

What're the pros and cons in regards to those subscriptions acting as reducers compared with using a tap operator in the original observable declarations?

[@JoshuaMorony]

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.

[@tolstoievski4926]

are you going to make a video about your transition to neovim and how you configured it

[@JoshuaMorony]

I sort of have some videos like that - this one sort of covers the transition: kzbin.info/www/bejne/l3TKdaZug9tgoNE and this one covers the general workflow I use: kzbin.info/www/bejne/hma0gZSZr5dgl9E but I don't have a full from scratch style configuration video

[@jonathangamble]

The problem with all this is that in reality it would be first loaded on the server with SSR for seo (which would be promises), then hydrated and subscribed to changes...

[@JoshuaMorony]

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.

[@jonathangamble]

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

[@JoshuaMorony]

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

[@LarsRyeJeppesen]

Absolutely

[@Animesh878]

Is angular still relavent in 2024?

[@armynyus9123]

wow. Subbed. Totally.

[@CptProv]

Would you use signals to keep the state of errors too? Also, is this approach in your course?

[@JoshuaMorony]

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

[@TheBlockUniverse]

What's hard about storing the state in RXJS? Is it the fact that the state is asynchronous? I feel like the whole signals implementation could have been avoided if they integrated more tightly with observables. Coming from react to angular, I've noticed that not having to care about updates/re-rendering in angular has only lead to a bunch of horrible code, where it's impossible to understand the flow of data, but maybe that's just bad developers I've encountered ¯\_(ツ)_/¯

[@JoshuaMorony]

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: kzbin.info/www/bejne/n3KZmqylltOnq9E

[@boris8983]

so Rignals it is - let's make it a thing

[@alandragicevich2421]

The one big shame about this RxJS/Signal interop all the extra closures. RxJS isn't that performant in the first place (although still fast enough in my opinion, supposedly just as fast as native iterators). Signals on the other hand are much more efficient I think, due to being built off of the proxy object system? So deep down, it hurts thinking about the extra unnecessary memory overhead. But at the end of the day, probably doesn't matter... Plus I can't stop using RxJS. I love declarative programming too damn much 😅 Edit: I still don't know why they couldn't just modify the async pipe to be smarter so it doesn't rely on ZoneJS.

[@JoshuaMorony]

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

[@tarquin161234]

I thought ZoneJS isn't needed for async pipe bindings? I thought using async pipes allowed you to use the new zoneless option?

[@alandragicevich2421]

@@tarquin161234 it does now. I wrote this 9 months ago before all of that was a thing.

[@sulaimantriarjo8097]

i think, it makes more complicated for beginner to learn angular. btw is the current signal implementation still using zonejs?

[@LarsRyeJeppesen]

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

[@sulaimantriarjo8097]

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

[@finleybaker6008]

This video makes my head hurt. Which is actually a compliment as someone whose rxjs codebase is a migraine factory.