Someone on reddit pointed out that the placement of the catchError would mean it only handles the first error, I've fixed this up in the source code but just be aware of that in the code shown in the video
It is really nice with the visualizations. It helps a lot when looking at the side-by-side with the code :) Keep it up Joshua, you are doing good work.
Signals (Angular signals specifically) only is possible only until you need to handle anything async (like the http request in this example). The basic idea with signals is that you just use computed to derive anything that is dependent on some other thing. Then at the top of your graph you might have a standard writable signal that you can imperatively set to trigger everything else below reacting to it. Once you need to deal with async stuff though you will need to bring in RxJS or something else if you want to keep it declarative (derivedFrom from ngxtension is an option, which allows you to do async stuff with signals with the RxJS stuff hidden behind the scenes)
Do you have an take on how to avoid reassigning when you want to subscribe to an event-style observable (e.g. ionInput of ion-searchbar) of a component that is being fetched as ViewChild (in angular)? Is there a way to work around the fact that the ViewChild/CMP reference will be undefined in the constructor scope?
@@JZubero yes I'm not at my computer now so can't grab the exact link, but I have a video titled something like "refactoring my ugliest code" which is about how signal view queries make this much easier, but I also show how I did it pre-signals
Great video as usual! I’m a big fan of your channel. I looked at the GitHub code and correct me if I’m wrong but it looks like if there be let’s say a connection error with the back end that error will not be handled because in your error handling you rely on the fact that back end returns something
This should work with any kind of error on the observable stream, though you will have to modify it to more appropriately handle different types of errors - this example just naively prints out whatever the 'error' property of the notification is (but with an http error that is going to be an object)
I think that's intended behavior for this graph. Otherwise, the graph would be more linear (filter => page => request => data). The example is illustrating that either of those things will kick off an http request, that will return with updated data.
Yes you're correct and yes I think it's sensible here to reset the page to 1 when the filter changes. Without getting into different types of approaches, the easiest approach for this example is probably just to next the page BehaviorSubject with 1 as an imperative side effect of the filter changing. Since we are using switchMap and Angular's HttpClient here we don't really need to worry about our combineLatest stream emitting multiple times
