Here is the prototype of the signals lib: #49091

So basically, it is the Reactivity API from Vue with different function names?
Do you have any idea yet how we use it in our HTML templates? Will it be always the function call to extract the value?

In Vue, it is possible to just use the property name, which makes it easier.

In Vue, refs are not functions. You can do {{ foo }} instead of {{ foo.value }}.
With signals as functions, you would just do {{ foo() }} to get the value, and {{ doSomethingWith(foo) }} to pass the signal itself around.
I'd rather stay consistent with the way it's done in TypeScript than allow avoiding two parentheses and wonder why it would call the function.

Here is the prototype of the signals lib: #49091

Not sure why I muted notifications for the post. Anyway, I tried the demo and it WORKS. My only complaint and you addresses it in other comment is the syntax. I wish there is way to directly to get value instead of declaring const readOnlyCounter = () => counter(); or using counter() in template.

const counter = signal<number>(0);

I will play around with it more in coming days if not weeks

So, can I remove zone when I use Signal？

@chen-yangfan yep! That's the goal

I hope we'll one day make the list!

I think the best way to consume StateAdapt will be with signals. Signals are like the async pipe but not tied to the template. They will have a net simplifying effect on components, despite introducing a new concept. The truth is that there are 2 branches of reactivity: event and state. RxJS (push-based) is best for events, and signals (involving pulling) are best for state.

State selectors probably still have a role in defining portable state management patterns, but I have yet to try to define state adapters with signals.

Not sure if you saw, but I talked about this in my article here https://dev.to/this-is-angular/i-changed-my-mind-angular-needs-a-reactive-primitive-n2g

Couldn't one easily make a decorator to wrap a signal in a getter and setter?

I'm not seeing the downsides here

I'm pretty sure Angular will die quickly if they commit to using hooks for reactivity.
Hooks are one of the most awful design choices that have ever been made.

Hooks are just functions. The awfulness comes from React's rendering model. And hooks are still far superior to what React had before.

No, hooks are not just functions. They are functions with the internal state.

Yes I want to use RxJS and I want Angular to improve their integration with RxJS instead of making up new things, that could turn out to be a failure in another 7 years. Another operator needed? No problem, make it. But not a hook-like "something else".

Even if @haskelcurry did not take the most diplomatic way, I think he is right in the core statement. In addition, the whole signal topic seems to be very competition-driven - at least that's how it seems to me.

Also, I don't think Angular really needs to be made more beginner friendly or that it should be focused on that.
As @haskelcurry said on another comment:
Improve Error handling. Improve Forms. DevTools. HMR. Elements. Schematics. DI. Improve type checking. etc.

I think the way should be to get rid of ngZone with existing means instead of introducing a new concept.

As someone who teaches Angular within my company, I definitely welcome the easing of the learning journey, and I think it's something the team probably gets feedback on a lot. With standalone components and this evolution, if feels like they're working towards making the framework more approachable to new devs, while also dealing with the architectural issues (zone.js).

Hi all, I'd love to encourage move this discussion to the correct place, since HMR is not blocking or tied to this proposal, and both will improve Angular.

@dgp1130 wrote up a great issue of ideas on this topic here: angular/angular-cli#24755

Well, others have had to add proper HMR & SSR support instead
https://github.com/analogjs/analog

@davidivkovic I did FP/FRP on commercial projects with Haskell, Clojure / Clojurescript with re-frame, Scala on the backend side, Elm, CycleJS, SolidJS and of course React (which is btw also far from true FP, despite their claims and pretending) for decades. I'm with Angular since the initial release of AngularJS all the way through, on enterprise-grade commercial projects in production. And I can tell you that Angular is not FP nor FRP, just by design. Neither it is a decent OOP. Adding +1 concept won't change it.

And do you really think people won't start doing NgRx / Redux / other-overcomplexifying-you-name-it on top of Signals too? Ha! It's not an "integrated state management". It's just an RxJS BehavriorSubject + shareReply + distinctUntilChanged out of the box. So why then all the fuss about? Just provide a new RxJS creational operator, that's it. But guess what, it won't change much. Because it's not the reason of failure.

They are moving from one idea to another, following the "community demands", rather than just settle down the good parts that they have - not much, but they are present in the framework, just ruined by lack of attention "because it's just a nice thing to have, not more". Improve Error handling. Improve Forms. DevTools. HMR. Elements. Schematics. DI. Improve type checking. etc.

@haskelcurry BTW the list of features you mentioned have all seen improvements recently or are in the process of being improved right now except maybe Elements. Error handling has and is improving to be very developer friendly, even going to show element and it's event like normal html, Typed Forms came out, New DevTools released, Esbuild is almost done so proper HMR can be supported, we are gettinh new schematics to support standalone, inject function is a different method for DI and can now be used inside constructor.

@dolanmiu @tayambamwanza
Do you think I care about you clowns?

@dolanmiu @tayambamwanza Do you think I care about you clowns?

Thanks for answering my question

@davidivkovic this place is reserved for technical discussion. Please observe our https://github.com/angular/code-of-conduct

To answer all those that wish for a real answer on rxjs vs signal or why signals are needed - as someone who tried to "fight" state using observables and tested the new signals I can say signals are a huge improvement for sync state. Using shareReplay and distinctUntilChanged help solve some of the problems but the main problem is the diamond problem. The moment you use combineLatest you encounter the "glitched selectors" problem. The only way to solve it is using a scheduler which makes it even more complicated.

Now let's take an example - you created a selector using combineLatest and saw the glitch effect so you add asapScheduler and it works! But now this new selector is suddenly async. You have three pitfalls now:

1. Update the state and access right after the selector will result in stale data so you have to "wait" (probably skip(1)) for the updated data - thus making each regular function that needs state access into async function with rxjs.
2. You can't just bind to the template with async pipe as the data won't be ready in time (it's now async) - so you need viewModel with ngIf around your whole template to wait for the async selector.
3. Can a derived selector be sync? How about half sync half async? Do you suddenly need to make all the selectors async?

Those are the reasons by the way that made ngrx use a custom selectors model. The downsides were explicit dependencies (not such a big deal) and the requirement for explicit global state graph which suffers from drawbacks in local states (see this). The answer was component store - which has the problem from above (see debounce).

Now imagine having state and selectors without glitch effect + memoized + batched and on top of all lazy but always ready when needed? In addition they are sync so no need for rxjs when you just want to check something in the state or bind to the UI (now rxjs is really just for async operations). Guess what? That's signals :)

So a big thanks to the angular team!
That's my opinion anyway.

Here's how it's gonna be, remember my words:

1. They'll say "we invented new cool thing, Signals! It IS NOT a replacement to RxJS, rather a great addition!"
2. (After 6 months) "Angular Signals are better than RxJS and here is why"
3. (After anohter 6 months) "RxJS is deprecated in favor of Angular Signals, but here are our semi-working schematics to ease a migration process for you"
4. (After anohter 6 months) "We have re-written our Engine, now it's called Angular PopCorn™️, all libs should migrate or else they won't work"

Hopefully HMR is done by that time.

Correct me if I'm wrong, but signals as they are implemented are synchronous. While RxJs allows you to handles asynchronous tasks. I think both will still be needed, along with the conversion between observables to signals and signals to observables.

@haskelcurry Have you used RxJS? It sounds like you haven't. It's pretty great, you should give it a try.

@haskelcurry even though your way of saying stuff is unfiltered but your timeline looks very true and so it makes it even funnier, now ng team has to come up with alternative solution for saying this too. But with that said even though HMR is a pain in the neck so does zonejs. It would be nice to have some other solution. For Rxjs part it is great for doing reactivity but having to use so many operators is also a pain when I can do something simply and even if down the line they say it was a bad alternative so what we can have something else but if you are using angular you should be appreciative and that doesn't mean you have to agree with what they say or anybody say, All you have to do is think before you write and think about how many hours they have to spend to make this work and the stress that comes with this to not break thousands of apps and keep the codebase backward compatible while transitioning. Anway's, looks like you have great insight on all of this than I might ever have but putting your opinions forward like you are not stabbing someone would be great.

@menosprezzi The concepts signalFromObservable() and observableFromSignal() are in the planning.
So there is going to be full interoperability between the two concepts.
They complement each other and do not take anything away!

What signals really open up in the feature is an alternative to zoneJs. I'm really looking forward t that future!

@SanderElias nice! But I mean that implementing InteropObservable interface you can use the signal directly in your rxjs pipes if you need.

For instance, lets say that angular changes the @input to wrap values into a signal, you can still use it with the rxjs's reactive utils if you need:

class MyCmp {
  @Input()
  value: Signal<number>;

  ngOnInit() {
    const aNativeObservable$ = this.myService.get();
    combineLatest([this.value, aNativeObservable$]).pipe(/* and so on :D */ ) 
  }
}

This will ease the migration between both!

@menosprezzi The concepts signalFromObservable() and observableFromSignal() are in the planning. So there is going to be full interoperability between the two concepts. They complement each other and do not take anything away!

What signals really open up in the feature is an alternative to zoneJs. I'm really looking forward t that future!

I think signalFromObservable() is really essential to have in place when this lands. It also has to automatically handle the subscription. If this gets done right it will be a really nice solution.

wou, what @menosprezzi said is interesting

here is a link to the pr for InteropObservable tools. #49154

They mentioned it 2 times:

Significantly improved interoperability with reactive libraries such as RxJS.

Bidirectional integration story with RxJS reactivity

I think it means that they are taking care of it and you don't need to worry about your existing code, relying on RxJS. Also, this tweet might be helpful

And if you're an RxJS master, you'll be able to leverage our RxJS interop to compose Observable inputs, queries, lifecycles into your streams.

@e-oz Sorry... 🤦‍♂️

No @IRod22 you shouldn't be sorry, because you are right: there will never be "magic", even though they claim there is, like with NgUpgrade. Any interop will help us only partially, but there definitely will be a need to worry about existing code.

and 3) what will happen to forms? How will they be affected?

#49090 (reply in thread)

@BruceWeng Yes, they will be available wherever you want to use them. You can use them in services and functions and wherever else you might need a reactive primitive.

A fine-grained state management solutions could / should be build on top of signals. We don't have any immediate plans of designing / implementing Angular's built-in one. But there are well-advanced, community-driven efforts, ex.:

• [Closed] RFC: NgRx SignalStore ngrx/platform#3796
• Draft: signal prototypes rx-angular/rx-angular#1523

I think you are right for everything that is not a really simple app that should not evolve over time. But there are also other cases.

@timonkrebs the thing is if it is that complicated for a simple example what will happen when you have a list of data rendered as a grid with column filters and sorting and checkboxes but also as a list on another screen with a dialog to edit data in specific cells. If it all flows from the UI as observables directly I am not so sure it will be easy.
My point is rxjs is awesome and operators are awesome but going with it all in can sometimes backfire. The most important thing is data consistency and a single source of truth state. To achieve that you have selectors and updates avoiding the diamond problem. Signals will shine in this area. Once you get to async operations you should use rxjs as it simplifies the code and makes it easier to reason about.
I think that so called "pure FRP" shines in simple cases and once you have a lot of UI events all connected to some global state you get to the point a new feature or even UI changes can lead to a lot of code changing. Combining imperative updates together with reactive single source state and selectors with rxjs for async timings seems like a good match.

@Harpush I fully agree with you. I am not at all a FRP purist. I did agree with him on:

In reality first come codebase. Already existing code base which already do something. And the business consider it's working fine.
Then they throw at you problems. And you need to code them. All while keeping previously established correctness of your application intact.
So reality is not implementing new features, no! Far from that! Reality is CONTINUOUS REFACTORING. And for that you need to keep your code in certain state,
Always ready to be refactored.

The other stuff was discussed befor and I have never seen a reasonably complex app that did got 100% pure FRP working. So I do not want to get into this discussion. I think your points are really a lot more important. Never the less I also think that there are usecases that fit 100% pure FRP.

@timonkrebs maybe there are... Especially simple ones I believe. Concerning what he wrote it is true for non frp apps too :)

Thank you for the heated discussion. I really enjoied it sometimes. At least I now feel battletested when it comes to discussing signals. Hope you can also take something out of this discussions...

@robounohito You are very, very confused about RxJS and what is wrong with subscribing manually. When you read from a signal it is the exact same thing as passing an observable to the async pipe. You are hyper focused on the () syntax instead of code organization. As long as you don't use next or set, you can structure both observables and signals in a 100% declarative way. The manual subscription is not the problem! It's the code people write inside it that's the problem, because the only thing you can possibly do is write imperative side-effects. But actually causing a subscription is identical to what you're doing by passing it to the async pipe! You think it's going to change your code organization whether you are typing value() or value$ | async? Not at all! So are you really worried about code organization, or are you tripping over a meaningless syntactic difference? value() is a read, and 100% declarative, same as value$ | async. Any way that it affects any signals above is the same way the async pipe affects observables above.

@mfp22 I think you are right with what you wrote. But I think he will not be the last guy to get upset by the introduction of signals if we can not make really clear what it is that signals bring to the table to justify the introduction into angular.

I am a huge fan of signals and think its the best feature that was introduced since the introduction of angular. But I also can see how devs would not see the benefits of signals over rxjs before really working with them in complex apps. And I fear that they will not get adopted in the wider community if the devs do not get the real benefits. Because:

• they seem just less capable than rxjs (Because they hide most of their strenght to be intuitive an ealsy to use).
• it is not easy to define where to use signals and where to switch to rxjs ( Where are best practices)
• signals do a lot that zonejs and the cd did for free (sure with some edgecases but a lot of people did not get these and hack around until they seem to go away => for example NG0100). With signals some of that now gets pushed into the mind of the devs ( and it seems also devs would be responsible like in rxjs). But most will not get it, without making it really clear, that signals are much more a solution to fix the edge cases like NG0100 than a solution to what they (sometimes have to) use rxjs for... And I can see how it feels just like an other (even worse because less capable) solution to the problems that they now solve with rxjs.

There's no initial value if the Observable doesn't emit the first item synchronously AND you don't pass in initial value. You'll get an error if the first time you read the Signal, the Observable still hasn't emitted. That's the current impl

There's no initial value if the Observable doesn't emit the first item synchronously AND you don't pass in initial value. You'll get an error if the first time you read the Signal, the Observable still hasn't emitted. That's the current impl

Throwing would be much better than emitting null / undefined. That would be great.

I am secretly hoping for a fromObservable pipe in Angular...
Then the RxJS lovers can do their RxJS stuff as usual and benefit from faster CD without the need to introduce Signals in the TypeScript code. The fromObservable pipe would most likely not have the strange null typing issues of the async pipe.

<p>{{firstName$ | fromObservable}}</p> 😍

@mfp22 @spierala the plan is to throw if an Observable doesn't emit on subscribe. The way to "prevent" this error is to provide a default value.

I just added a comment. This approach could work, but I would rather have more TS safety.

Just throwing in my 2 cents here...

RxJS doesn't distinguish between observables that emit immediately vs asynchronously. So I don't think consumers of observables should rely on knowledge about when they're going to emit. This could cause unexpected errors. Much better would be to type it as T | null always, but optimally let devs pass in a type argument (or infer from initial state passed in) if they happen to know 100% that the observable emits immediately. But in my opinion even this explicit type parameter is dangerous because you could modify the observable upstream and TypeScript could not prevent a runtime error. And I don't see a significant difference between null and undefined here, but I haven't thought that through carefully.

The only way safe way out of this TypeScript awkwardness is if the observables themselves contained knowledge about whether they are going to emit immediately or not.

@mfp22 I do agree with you reasoning. The dangerous situation here is that we a given observable might be emitting on subscribe (synchronously) one day and then someone adds an operator somewhere that marks the observable chain as "async" and parts of the application code start to throw. I can see how this could lead to hard-to-diagnose errors.

@alxhub we should probably revisit this and / or ask for feedback in the RFC.

That's what computed is for

Exactly, the computed is essentially a selector built-in into the reactivity / framework.

One that doesn't require a centralized store :)

Yes :-)

One that doesn't require a centralized store :)

That's one important statement and a big drawback with current implementations

Yes! We are not talking about it enough but the reactivity discussed here is not "trapped" / constrained to a component tree. Or services. It "just works" anywhere you need it!

@Harpush

The first example creates a new object on any change, so the result is not the same; thus, any dependencies are executed.

It's true, of course, but how it's possible that the new object created indirectly works without the effect of logging (a new object is also created)?

derivedPropA = computed(() => this.customObject().propA);
derivedIndirectPartialA = computed(() => ({ foo: this.derivedPropA() }));

The second example ...

It's probably a misunderstanding. The question was, what exactly does an object property (or a reference change of any inner object) mutation mean when the object reference is still the same? And when the related effect (binded only to this object) logs.

effect(() => {
      console.log('Derived Custom Object:', this.derivedObject());
});

As far as I understand every call to set or update or mutate marks for change. So immutability isn't required.
Anyway derivedPropA is getting memoized so derivedIndirectPartialA don't get affected by non propA changes.

So there are 2 things at play here:

• change notification;
• equality checking.

As @Harpush pointed out, every change method (set, update, mutate) is sending the "changed" notification to all the dependencies. But this change propagation can be "blocked" if an equality method determines that te 2 values are equal. Also, all computed are memoized based on this equality notation.

Our default equality comparator checks for primitive values (strings, numbers etc.) equality, but always assumes that 2 objects are "unequal", effectively making it possible to work with mutable data structures. If one prefers pure immutable data structures an alternative, more strict equality function can be passed as an argument to the signal / computed.

@pkozlowski-opensource is it something that can be globally configured? Or atleast at DI level? So you don't have to pass it over and over? (The equality function)

We can discuss this during the RFC. But generally speaking we would prefer to avoid global config as one can achieve the same effect (pun intended!) by wrapping the signal / computed functions in your own - you could even name those as signal / computed and export from a different entry point.

Having conversion in a TS code assures that we are not creating subscription-side-effects multiple times when accessing the same observable multiple times in the same template.

The fromObservable pipe would be an extra. You could still use the fromObservable function in TS code.

The async pipe also creates subscription-side-effects multiple times for accessing the same observable multiple times.
It would be even desirable, if a fromObservable pipe behaves the same way (for consistency).

I think this will be beneficial for the huge RxJS codebases without the need to go through that much refactoring. It will be great if we have something like this included out of the box in the Angular signals library.

Is it true that all of the points mentioned are questions concerning perf optimizations (except the type safety)? Or do you see bigger problems with it? I think the performance problems mentioned could be optimised quite easy in every stage of development...

Maybe the problem could be eased even further with providing pipes for consuming signals:
#49090 (comment)

The scheduling of signals is not optimal for all cases! For debugging or hardcore perf optimization I really would like to have more control over the scheduling! The problem described here could also benefit from this, as it would make it a lot clearer to advanced users that there are more complex things to consider if you need to optimize for perf.

Concerning the type safety guards and the as syntax I think it comes down to providing best practices as I already mentioned in: #49090 (comment)

I think best practices are really important to get a introduction of signals without too much resistance from several corners of the angular community.

Maybe add to Best Practice:

• Do not use as syntax with signals (if you want to optimize for perf). (maybe provide examples why it could be problematic)

I really think for educational reasons it should be possible to not have automatic triggering of the pull cycle of the signal as demonstrated here: #49090 (reply in thread)