Here's what I've figured out about Angular signals

What is the point of calling toSignal? What is the benefit? Why not to use just selector with rxjs pipe(map) and bind with async pipe?

here's too many layers and too much abstraction, Angular jobs are much fewer than React and if they keep adding all this Angular only sh!t it's going to put off even more devs. Relearning everything ever few years to get same result is poitless jerking off. Love your vids!

How I'm approaching signals at the moment: I'm just not. I don't need signals. Declarative rxjs is just fantastic. The only problem is most of the people in my team don't want to learn it.
The other thing is, I think toSignal is a bad idea. This is because, in my experience, the initial arbitrary value we provide can cause problems in client code such as calculations in effects. For example, I calculated in an effect a default value for a form field (for when it is null); this did not work correctly with toSignal because the first set of arguments passed in contained the arbitrary value, not the db value.
My main problem with signals is making asynchronous code synchronous with these arbitrary values. It goes against my developer intuition. There could be unexpected consequences of doing this.

I noticed the code in the video is different than the code in the git repo. Is there a reason for that? Example no shareReplay etc.

Speaking of Zoneless.. as Angular/fire just appears to not be really updated any longer, does anyone have experience with just using native firebase library for Firebase access, in Angular? Any issues? I have to move away from Angular/fire, as our app is now zoneless

This video was really useful, thank you so much. I have a question: for the sources, we have retry$, currentPage$, and error$. I think error$ will be needed in almost every service. Is it a good idea to create a new model to encapsulate those sources? For instace creating a model like SubjectData<T> derived from Subject? I thought like this might reduce the boilerplate code.

I completed your course a week ago and am now engaged in a personal project involving Angular + Firebase. I'm developing a Dungeons and Dragons platform to enhance spell management during offline sessions with friends. Currently, I haven't found a platform that meets my requirements.

I thoroughly enjoyed your course and would recommend it to anyone embarking on their Angular journey. I continue to revisit the material daily, discovering new insights and gaining deeper understanding with each read.

Although your course includes a section on the ngextension library, I've chosen to focus solely on Angular/RxJS, implementing the Redux pattern as you taught. This approach feels intuitive to me, and I prefer to grasp the fundamentals before delving into additional extensions.

Thank you Joshua, and I hope to find a job on Angular in the near future.

How would you handle stateful forms? What would the source be for a submit action?

just make it easy to write and explain, all declarative code is nice is theory but only works if you're in a team with 10+ experienced developers with the same mindset. It's good to sacrifice some 'good' code for 'bad' code to not make everything over complex. Do you even understand it well enough to explain it to the 5 new junior devs? What if you introduced the all declarative way (tosignals in this case?) but can't solve the giant bug it caused? Do you even know how to unit test it?

I ran into a bug with my reducers, sources and switch map. I think the root was the double subscription. In my switch map I would return EMPTY if the request was not needed but my status would get stuck in the loading because of the reducer. I couldn't fix it so I just put the reducer in the switch map.

I dealt recently of listen to 2 signals as an observable streams, to then use toSignal + switchmap with the objective of basically listen to changes of that signal a simple example could be for example transform the typical activerouter.params -> toSignal but then also use a similar setup of merge + toSignal + switchMap to listen on changes of that signal based on the router params and do a request based on that params

And first problem obviously was the requests triggering twice because it has 2 different signals on load and both changes on the initial load.
Sharereplay doesn't helped and also i tried use combineLast, forkJoin is funny because it causes crash the devserver.

But the part I'm worried about is something you don't see in a first instance if you don't check the network tab in the debug console.

I love the first approach to deal with all of this but i find it risky for people as you said with some skill issue i think is pretty easy to do a mistake and introduce cases of triggering subscriptions when you don't want/shouldn't.

So after so much headache our team forced ourselves to use NgRx instead of our complete mess of observables and state services. The upside is the newer devs can use all the stores but the boilerplate to set it up is a bit daunting. Sooo using signals as redux lite might be a really interesting balance between the Cathedral of NgRx and the anarchy observables as state.

Actually, I don't think subscription from an observable steam to signal state makes code "Imperative". In React or any other framework, it's natural to do setState logic in UI's event handler, just like a two-way binding mechanism.

Using rxjs to manage state is a nightmare, it requires high level of rxjs skill to achieve some basic and easy operations which signals can do. Which definitely harms the code readable and maintainable.

I found out... not using signals at all

this whole declarative thing has become like a cult, honestly, I don't agree with ' sacrificing a small amount of declara-ness' because it didn't make the code better so you didn't lose anything.

How do you use takeUntilDestroy without injecting a DestroyRef?

Your content is high quality, relevant, and I really enjoy it. However, it would be good to include some reflection on the challenges faced by Angular, particularly in the context of RxJS/Signal patterns. It’s concerning that it might take an Angular expert an entire year to settle on an effective pattern for managing reactivity within Angular applications. To clarify, I believe the root cause lies in the introduction of signals and the potential impedance mismatch it introduces when compared to the existing async primitive (RxJS).

My dopamine somehow increases whenever I see RxJs with Signals 😂😂

The more I know rxjs it's harder to not use it, because there are a lot of things, that are easier to accomplish than with signals (think scan, debounce, merge, withLatestFrom etc.). But yes, you have to keep track of all the (invisible) subscriptions because they can bite you if you forget a share at the right place. As always: failures have to be made to learn from them. And even a relatively simple component has often more events than state - I can't think of not using rxjs.

I've been in camp #2, using RXJS sparingly but not eliminating them.

You are right. For newbies, Redux is better, and it is pointless to expect them to write a perfectly declarative code. I was there, I know it from my own experience. And when one can notice the downsides of that flexibility, they will migrate to a more declarative approach. Nothing but experience can help them.

The more I use it, and the more I see content about it, the more I think Signals was a move in the wrong direction.

What is your opinion on ngrx signal store?

What's the best approach for api request?

.subscribe or toSignal ?

I think Redux style is a great standardization adding the benefits of Redux DevTools and is compatible with advanced RxJS data updates. Thank you

For me Signals replace the store completly. Now i use signals and services with signals as mini capsulated states. Like: SomeEntityService { state$ = signal({fuu:'bar'}); foo$ = computed(() => this.state$.foo); loadSomeEntityListByWhatever(whatever: WhateverType)} etc.. delerative.. but single point of truth is the backend, not the state. Much less overhead.. Much better capsulated. I dont mint using Observables in existing projects.. but signals.. no unsubscribe, only "computed" instead of map/switchMap etc.. "efect(() => console.log('effect here: ', just.use$().it))".. it is hype for a reason :-) ...

I feel like TanStack Query or Loadoff can simplify the status and error streams. Your thoughts?

first 😎