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

I can never go back from Signals.. it's SO nice.. and with zoneless it's just great

I know what you mean, I love ngrx but WE need to keep a close eye on our stores to keep them clean. On a medium project, I found NgRx Signal Store a very nice replacement for Component Store actually.

I feel Ngrx signal store more imperative that tradicional ngrx store

I don't see how observables are anarchy. Quite the opposite, as Joshua will tell you, they are a great way of simplifying state.

@@tarquin161234 I really meant using services to store and handle state.

See also: Reactive Forms vs Model Binding. See also: Outputs vs Callbacks. See also: Promises vs Observables/Signals. See also: Shared Services vs ViewChildren vs Injecting Children. Etc etc etc As an ex-react developer, I was promised "Angular apps look the same" but I find that if a problem had two different solutions in React, it has 5 in Angular.

I'm not sure if it addresses specifically what you are talking about, but I do have some videos like this one: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-iA6iyoantuo.html which essentially focuses on the question of "why would Angular want to introduce a signals primitive when RxJS can already do essentially the same thing" And I think we are in somewhat of an unavoidable hard period with Angular where there is a lot of new stuff, and no consensus on best practices around the new things. But I think we are starting to get to a point where different preferred patterns are emerging, and for most people who will adopt signals a little bit later down the line they won't need to mess with experimentation so much.

​@@BenjaminLeeds yeah, you are quite right. And also some very experienced Angular expert like to push their own custom store or stuff like that, and that's not helping in my opinion.

Maybe I'm missing a point here but if error$ is declared for the coming API errors, I'm catching and handling them in an interceptor and don't bring them into my component at all. Only successes are handled in my components. Please let me know if error$ is referred to something else in the context.

computedAsync from ngxtension does provide a reasonably nice way to go about this in a way that feels like you're just using signals, but it is still technically using RxJS under the hood. But yes, with no abstractions the way to achieve a "signal only" style approach for async situations (and to be clear I do not like this approach) is to use effects with allowSignalWrites

Shots fired. I don't consider myself a newbie (12 years experience, 4 in Angular), and I've given both approaches fair shots, but have decided that the Redux style is easier to maintain. The reactive style has too many cascading effects that make it hard to debug and reason about. Not to mention the cumbersome mechanics in RxJs.

New feature in angular 16

Use it at the constructor level - either in the constructor or field definition.

Sources can also be user actions e.g. in the example in the vid we have "retry", "error", and "currentPage" sources - retry and currentPage are triggered in response to user actions, error is called from within the code. So for submitting a form can have some form of "submit$" source that you next in response to ngSubmit, you could either supply that source with data directly, or when that source emits you switch/map to whatever you want (e.g. the form data which then gets POSTed)

The goal here was to work directly with the native concepts in Angular to give a better sense of the fundamental concepts/ideas which libraries abstract/hide. To be clear though I'm not against using libraries/utilities and do use them, generally for me that's either just connect or signalSlice but TanStack Query is something I've been meaning to try for a while (Loadoff I don't really know anything about)

Yes TanStack Query will simplify the code, buuuut is still experimental…

I'm yet to properly give SignalStore a go but I know it's great and I know a lot of people love it - my current preference is signalSlice (naturally, because I built it around what I like) but the APIs are very similar so signal store also feels quite natural to me. The main thing at odds with my own ideas around declarative code etc is the idea of using patchState imperatively, but the existence of patchState also doesn't mean I can't also write declarative code with SignalStore - I'll need to play with it

The issue with patchState() is not only in imperativeness but also in mutating the global state. It can easily cause unexpected side effects, endless loops and other nasty surprises. Look, people created a whole programming language to avoid exactly this :) (I mean Rust)

Both of these approaches work with with async/api requests - the example in the video includes this scenario (loading the articles)

toSignal internally calls subscribe

@@yankotliarov9239 then where does the unsubscribe happens?

@@mansoorabdullah when component is destroyed

@@mansoorabdullah also api calls autocomplete themselves after getting the result

I operate under the definition of declarative meaning "everything that defines the behaviour of this entity is contained within its declaration", so with that definition anything that involves reassigning the value of something from outside of its declaration is imperative

​@@JoshuaMorony fair enough, but just like what you said in previous videos, binding event handlers and "reassign" it to a (Behavior)Subject is also an Imperative way right? So, it's pointless to achieve a fully pure declarative style.

​@@lightyagami5963 yes even the toSignal approach which I am saying is "more" declarative here, also still has imperative parts because user actions need to be propagated to the Subjects or whatever mechanism you are using via an imperative call - so (if we are using services anyway) we can't really have "fully" declarative code in Angular (even if we could I'm not convinced it would be worth it). So this is more a case of figuring out where best to draw the line.

How so? I honestly love signals so far.

@@qwerty-or1yg I don't think the pros of using them outweigh the cons. Okay, they're “simpler” to control than observables, but in exchange for that you..: - Lose the 100% declarative nature of a data change pipeline that you get in an approach using 100% RxJs. - Mix two different things in this flow, and have to deal with them in different ways. - You lose the ability for the data to be subscribed to and controlled entirely by Angular in the template, going back a little to the first point of having code that is completely declared and “flowing” as the data streams are fed. In exchange for what exactly? Lower learning curve for beginners? I don't think it's worth it, honestly.

No man

input, output, viewchild and viewcontent signals are really nice. Also model signals for dual bindings. Don't have to write that much boilerplate. State management is better with signals. And you can still use toSignal or toObservable to switch between worlds. Since it is preview, it contains some bugs. I recommend at least 17.3.x for signals to be helpful for interoperability

​@@MarcusKaseder yeah, agree, reactive inputs are nice, and can make some components quite simpler than before. But I can understand this comment. Also, the problems arise very quickly with signals, when you try to make side effects and stuff like that. I would say that Angular is adopted for its opinionated way, and as this video shows, it lost a bit of it. Hopefuly much clearer patterns will arise, because I myself don't like the mix of observables and signals.

Even in this small example I think the small loss of "declarative-ness" does still have a noticeable downside. Take the "status" for example, in the more declarative version if we want to know what it is and how its behaviour is defined the only place we have to look is at the declaration of the "status$" stream. With the redux style approach (which to be clear I'm not against and am sort of advocating for here) if you look at the declaration of "status" all you can see is its initial value. To understand how it behaves you need to search for all instances where it is being imperatively updated. With the approach in the video, this is at least limited to only occurring within the subscription to the sources rather than potentially coming from anywhere, and since the value is being set into another reactive mechanism (the signal) we can still derive other things declaratively from that.