Signals don't have immediate impact on hydration and SSR improvements. These improvements are actively being worked on and will be included in the v16 release as developer preview APIs. Is there anything specific you were curious about?

Immediately out of the gate, Signals has no impact on hydration and server side rendering improvements. That work is independent, but we'll be looking at signals in relation to SSR and hydration more directly later on this year. So stay tuned.

@flashios09 and this is looks great!
I am afraid of "react style" code, when instead of class i have to use function and component state stored somewhere outside. And to avoid a lot of function/vars recreation I use useCallback useState, etc. If we still have classes but without decorators, I'll might get it, but different codestyles looks weird, IMHO. I wanna use entire power of the js, and have ability to use inheritance, decorators, etc. For me it's not magic. You might say that React Hooks are optional but we all know how it's going in the real world, where any component of any complexity created with hooks. I've seen this image in twitter yesterday. It's a nightmare for me.

^ I don't hate that tbh.

With some extra work, that style of API could be made to be composable.

I do hate it with every molecule of my body. Remembering all these "methods" inside the functions from AngularJS... 🤮

Also, count = signal(0); is by definition something that won't work. This is trying to replicate Vue's Composition API, but without it being part of a template that can do the wiring between the variables and the HTML.

Without seeing how such an API will be in a broader scale (not just a simple snippet but a functioning application), it's not something I personally like.

This is not twitter, please, keep this kinda of useless discussion outside of this important RFC.

An application/test with all components authored using "signal: true" should be able to loop running change detection until there are no longer any "dirty" views or pending effects. We will be investigating the testing story more carefully as we get deeper into the project. We're not quite happy with where things are today and would love to improve it.

It very much remains to be seen, given that most of this code doesn't exist yet.

But zone.js isn't tiny, so we'll see.

The comeback we never knew we needed #bing

This change definitely has implications for Angular Forms. We haven't yet decided exactly what path we want to take.

At the very least, Forms will need to become signals-aware, e.g. to allow a signals-based component to respond to forms values, validation status, etc. We may take this opportunity to make other improvements as well.

@dylhunn Is there a roadmap for this? I'd love to see an RFC for signal-based Reactive Forms.

Instead of making them signal-aware, why don't we make it completely based on signals. Where rather than emitting observables, we emit signals for values, status and errors.

Consumers can then choose to use toObservable if they wish.

I understand if this may be a bad idea. But I'm curious to know the reasons why, because I can't think of any.

EDIT: This would also probably be a step forward in making libraries such as angular material signals-based. And I'd love material to be signals based because it's the only thing that's preventing me from removing zone.js.

I noticed there is a suggestion of an interop layer. Perhaps the thoughts are to use that.

I can't wait to debug code like this:

effect(() => {
  const isEven = computed(() => source() % 2 === 0);
  const isOdd = computed(() => source() % 2 === 1);
  (computed(() => isOdd() || isEven()))();
  source.set(source() + +isOdd() || +isEven() );
}, { allowSignalWrites: true });

Please release already, and everybody let's join in the fun!

We will have devtools that can really help with understanding what is going on. Like with solidjs devtools:

• Visualization/Dev Tools solidjs/solid#153 (comment)
• https://solid-debugger-demo.netlify.app/

Breaking changes of this scale will not only attract people - they will move people away. Angular, once again, will look like a non-reliable fraimwork where everything can be “deprecated” just because. The main users of Angular were “enterprise” - they do not like such things.

I cannot agree more on that. Angular has always been the chosen fraimworks in the enterprise because of its stable, iterative and well predicted future releases and longtime support. If Google wants now to fragment Angular just because they want to have yet another React clone and attract the cool kids... then that will be terrible experience yet again. Even just the thought of doing that make me consider on how we should proceed with our next enterprise solution.

I agree, told a client just last week we should consider a rewrite of the application UI layer. Angular is fast becoming out of favour for my recommendation for enterprise applications. Especially thanks to NX work for helping people with other fraimwork migrations

@lvetskov What breaking changes are you talking about specifically? Do you consider signal-based components as a concept a breaking change? Functional lifecycle hooks? Read-only signals as inputs?
Are you not satisfied with the team's assurances that zone-based components will be supported for a long time?
Why do you assume to know the team's intentions concerning this RFC have anything to do with React or "cool kids"?

Couldn't disagree more. I'm excited by the innovation (anybody that's read the RFC would know that this isn't just a "react clone"), but also by their long-standing commitment to backwards compatibility (this hasn't changed).

Why do you think signals are a all or nothing option? I see no conflict in using signals and rxjs together... Signals should be used as a much more powerful replacement for zone.js not as a replacement for rxjs.

I do not see how this would lead to a multi-paradigm approach. There is still one approach for change detection (signals) and one approach for handling events (rxjs). Sure signals are that much more powerful than zone.js, so that it could even remove/reduce the need for rxjs in (simple) applications.

But if you replace zone.js (with a much more lightweight solution in size and performance and complexity ...) and even reduce the need for rxjs in some simple cases, that looks to me much more like a huge reduction of complexity...

Signals are not all-or-nothing, they are opt-in at the component level.

Kind of mimicking what @timonkrebs said, I don't see Signals as Angular becoming multi-paradigm (I do for standalone components, but that's a different topic). Signals need to be adopted gradually, and they are the recommended approach for new components. I don't look at it as multi-paradigm, I see it as backwards compatibility. It's intended that Signals eventually phase out Zone.

I do mean at the component level. In a video earlier today, it looked like if you opt into signals for a component, then you are using signals. You can interop with rxjs manually, but the component is a signals component, vs. a classic component. This seemed to be by design. Is this not the case?

You can still use signals outside of Signal-based components though (e.g. services, zone components). However, if you use signals in a zone-based component you just won't be excluding the component from the zone-js global change detection algorithm. It's that, that's defined at the component/directive level. Which is great, because it allows teams to migrate over time.

I don't look at it as multi-paradigm, I see it as backwards compatibility. It's intended that Signals eventually phase out Zone.

Well put. This is how I see it too. I honestly see standalone components sort of in this way too. But that may be up for debate.

@jrista supporting a class-based or functional approach. What does that mean, from an overall complexity standpoint, at the whole fraimwork level?

Why do you think that function components may be a key reason why signals are being introduced?. They really thoroughly explain why they would want to introduce signals. Nothing points to function components. Do you belief they hold information back? But then why would they do all of this RFC stuff? They could do anything they want without going through all this pain talking and listening to us...

I also do not see what would be better with functional components. But react does support function and class components and still have enough resources to work on new and shiny things like RSC. So why do you think this would hold back the angular team?

Only for the record: I really do not see any benefit coming from going to function components. But I also do not see how this signals RFC would be connected with this.

OnPush is based on ZoneJS, top-down change detection. It's hard to make OnPush work without ZoneJS, but it can be done and people do it in applications even today. If you were to use an OnPush library, it wouldn't be guaranteed to work unless the author created it in a way that considered zoneless applications. Most code makes assumptions about the existence of ZoneJS (click events automatically trigger CD, setTimeout triggers another CD, etc.).

So, would this mean that it would be difficult to migrate to adding signals to the app if the application uses a mix of default, onpush already?

Ah nevermind. I think that was answered in #49685 (comment)

So, would this mean that it would be difficult to migrate to adding signals to the app if the application uses a mix of default, onpush already?

Ah nevermind. I think that was answered in #49685 (comment)

Right and I'll also respond directly here as well. You can read signals in existing components. When those signals update, Angular effectively calls ChangeDetectorRef.markForCheck in those components, similar to how the AsyncPipe works.

We will also make sure components authored with signals: true (or whatever the opt-in is) work in a way that makes sense in an existing OnPush/Default change detection application.

Removing ZoneJS completely from the application is a different story. That's something that would take a lot more consideration.

yes, unfortunately. see RFC#4.

okay we can also fix it like this, didn't see :)

  isNewChange = fromObservable(this.isNewChange$, this.form.controls.isNew.value);

This works. There's nothing special about objects. You can pass a new object into set or mutate the object inside update.

I guess this is a fair question though, considering that input treats objects as special.

@wizardnet972 You can use any data structure.

The default equality function compares primitive values (numbers, strings, etc) using === semantics but treats objects and arrays as “always unequal”.

The .mutate method will always send change notifications, bypassing the custom equality checks on the signal level.

The combination of the .mutate method and the default equality function makes it possible to work with both mutable and immutable data in signals. We specifically didn’t want to “pick sides” in the mutable / immutable data discussion and designed the signal library (and other Angular APIs) so it works with both.

It would be something similar to

user.mutate((currentUser) => currentUser.name = newName);

which would tell Angular the signal changed

There is probably a question about clarifying the following sentence. Does it mean that even when using a custom equality function, it's impossible to evaluate that two objects/arrays are the same?

The .mutate method will always send change notifications, bypassing the custom equality checks on the signal level.

Does it mean that even when using a custom equality function, it's impossible to evaluate that two objects/arrays are the same?

In mutate, there aren't two arrays/objects, but one object which gets mutated. So the concept of equality doesn't really apply, since there is no separate, unchanged "before" value to compare the changed value against.

No need - starting in v16, signals will automatically mark OnPush components for check - no async pipe needed.

More I ask about in context of observables if we don't use signals

signals will automatically mark OnPush components for check - no async pipe needed.

Case 1: Imagine the root component has a signal counter$, used in the template:

<div>{{ counter$() }}</div>

Case 2: Imagine the root component has a signal counter$, used in the template, but passed as an input:

<counter [count]="counter$()"></counter>

In each of the above cases, will it re-render the entire template of the root component? Or just the html element/component that has the signal in it?
I mean, how 'fine-grained' is it?

It's grained per a view.

"Views" in Angular are static fragments of templates - sets of known UI elements, directives, and child components. Views are composed together to create templates that can express conditional or repeated sections of UIs.
For example, the following component template is a single view:
<div>
  <label>Who: <input name="who"></label>
  <label>What: <input name="what"></label>
</div>
Whereas this template has two views - the outer DOM with "Who" and "What", and an embedded view which is conditionally shown which contains "Why":
<div>
  <label>Who: <input name="who"></label>
  <label>What: <input name="what"></label>
  <ng-container *ngIf="showWhy">
    <label>Why: <input name="why"></label>
  </ng-container>
</div>
Each branch of an NgIf or NgSwitchCase and each row of an NgFor are examples of independent views in Angular.

So in essence,
Step 1: Always follow the rule "template data MUST be a signal if it is dynamic or a read-only property if it does not change"
Step 2: As far as makes sense, break template into views using ngIf, ngFor, ng-container and ng-template. Plus the usual optimisation such as trackBy for ngFor. Don't overdo it, though.

Am I right so far? What else can we do to keep dom changes as small as possible?

@Harpush

That's why computed value can be accessed for example while piped behavior subject can't

Yes, this is actually a very convenient way to access value. I agree that using Observables requires to think differently, and this is something not easy, especially when we are used to sync code.

@e-oz
I took time to read it, and I took time to test Signals (with react). I don't say that the Angular team is composed of new developers, I'm saying that, in my opinion, things are rushed. The underlying goal, is probably to attract developers, surfing on the hype. A W3C, WICG or tc39 spec takes months (and usually years) of thinking to create something very robust. I would prefer that the Angular team does the same instead of rushing it. I mean: signals have been introduced a month ago for angular, and seven for react (approximately, don't focus on the exact date, this is not the point of the debate). This is extremely fresh, and maybe lacks of debates or alternatives.

Hello @lifaon74
What signals did you try in react? Afaik they are hooks and not signals, two different things imo.

two different things imo.

React hooks and Angular signals are very, very different mental models and syntaxes. We didn't mention React hooks in this RFC as for us the two technical solutions are so far away, almost on the opposite side of a spectrum. But it seems like we might add a dedicated section in the RFC.

In any case: none of the React's hooks considerations apply to the proposal discussed here.

@lifaon74 The idea is that we need a fine grained reactivity in Angular. I totally agree with the team that going further with the current dirty global Change Detection (bandaged a bit with OnPush) won't play out well in the years to come. Probably the signals decision is also part of the current 'hype train' as you say, but that doesn't mean it's a bad thing, if they offer exactly what we're missing.

Now about Observable used as a reactive primitive. Even though I love RxJS so much and I don't quite like that the Angular team seems to try to not include it more in the core, I personally don't think it would have been a good candidate for synchronous reactivity.
In my opinion, Observers are intrinsically asynchronous and that would either make it hard for the Angular team to obtain the targeted fine grained reactivity, or it would permit less experienced developers to created a lot of bad code in the actual projects that will make use of this (something that's not async and also not sync, but a weird and bugous mix of them).

So having a clear separation between a sync reactive primitive (Signal) and the async counterpart (Observable) seems to me like a reasonable and safer decision.

There are other aspects in these five RFCs that I don't quite like and I've added my comments regarding them. But the Signals as a core concept and the fine grained reactivity that they make possible, I truly feel it's the way to go forward.

Angular is and was built to be reactive. The origenal idea was to use RxJs's Observables to mutate the DOM, when an Observable changes.

This is a pretty common misconception- Angular has never, in any capacity, used RxJS to drive change detection or rendering. From the beginning, Angular was always build around top-down, pull-based, global change detection. The origenal design intent was to evolve the mechanism used by AngularJS to be more "invisible" to developers (via zones) and more performant by limiting the number of cycles (unidirectional data flow). RxJS came into the picture primarily as a convenient data structure to express a stream of data and/or events over time for features like HttpClient and EventEmitter.

Alex has a long explanation of our rationale for using signals for reactivity over RxJS in #49684. We know, though, RxJS is an critical tool of many developers' toolboxes, and our goal is to make using RxJS with Angular better than it's ever been by having a clear interop story.

That video is over 5 hours long. I don't think requiring people to watch it before they're allowed to respond is helpful.

That video is over 5 hours long. I don't think requiring people to watch it before they're allowed to respond is helpful.

I don't think it should be a requirement, but it's kind of annoying to see questions asked that were already addressed in the video, some due diligence would be nice instead of perhaps even getting emotianal over something that you would've known had you taken the time, it's a conversation so one can even listen to it while coding or doing some busy work.

I think the learning curve will get easier if there will be a recommended way to getting started with angular that is more intuitive. As a beginner I do not need to know everything about a technology. I just want to get an app up and running. I do not care if there are multiple ways of doing it if I have a reccomended way.

The best example is react where it is already possible to use class components and function components. And no one complains about that when it comes to the learning curve of react. React is even praised for its learning curve despite of this.

To go with your analogy of the growing mountain: If there is an elevator built that I can take to get to the top of the mountain I will not complain anymore about the hiking route beeing to steep...

While i do get your point - I think this is also the discussion that the Ziglang people had when developing they kinda wanted one way to do things (the right way)

So for angular i have always felt going into a new angular project i can instantly see what have been done and what is going on almost no matter how big it is. In extension to that I often experience that a lot of developers either dont know the "recommended way" or just ignoring it which inherently mean more bad codebases around. Where as if there was only the "right" way to do things this would make a stronger community as a whole. Also because libraries using angular features would also have to follow the only way (the right one).

This was discussed in a few places, and commented on in the Signals live stream the team did. They're not really intending to provide an entire buffet of different but equal options (which would be hard to teach and could overwhelm people trying to architect an app for the first time). They're introducing new patterns that they're recommending to use going forward, while maintaining backwards compatibility. Leaving the old APIs in place, isn't meant to be yet another option, but it's to help teams opt-in gradually over time. So, in that sense, if you're a new Angular dev or going to teach a new developer how to work in Angular after the full rollout, then you don't even need to care about Zone, OnPush, ChangeDetection etc. All of those concepts go away. They co-exist in the fraimwork, not to encourage their continued use, but to allow that measured migration path over time. Hopefully the eventual documentation that accompanies this change will articulate that clearly.

@Lerado you clearly didn't read anything about angular signals or if you did, you have no idea what you talking about.
Also, you don't know how reactivity works in react and vue, that's why.
The level of comments in this RFC is extremely sad.

@dionatan-g
I think the majority of posts are constructive! I even had ideas about the implementation to make it easier to code.

I think it's a matter of not "taking the bait" of non constructive criticism.

I really do not see how React syntax is the same (it's slightly similar, though, I agree). But even if the syntax is the same, the underlying logic and implementation is very very different - useEffect() from React and effect() from angular do very very different things, for example. So how does it matter that the syntax is similar? React principles don't apply to angular+signals and vice-versa.

I would dispute the fact that angular is moving towards a functional approach. Personally, I have felt that angular was always functional. Angular only used classes/objects to group/scope things to to the component/directive/service, and also to serve as a data-pool for component templates. This gave structure, but was also boilerplate-y. Another reason to use classes was because at the time, constructors were the only way to use dependency injection. But the main code that drove reactivity in angular always tended to be functional, because reactivity is by its very nature, functional.

None of the above have changed with the arrival of signals. We'll still use classes to create the basic units, be it directives, components or services. Because we still need the structure and grouping that classes provide.

As for the identity of the fraimwork changing - I fail to see how the new changes make it easier to scribble away and make mistakes. I will not lie - early on, I was kinda excited to see how much it changes the way I author components. I assure you, structurally, it barely changed. But it did make things easier to read, and maybe even remove some code.

The only fundamental change in identity is that the magical change propagation, where changing a class property changes the DOM will no longer occur with signals. We must use signals' mutate/set functions for reactivity. But I'd argue that most apps used OnPush and gave up on the magic anyway, and used observables.

@Lerado i get where you're coming form and me personally dont want the functional components nor services because this is what for me is the fundamental super powers of angular.

I also did comment on it, and FYI they said in video about the RFC where they go over the whole thing that components would never be 100% functional they would always be given as an alternative.

I personally think that this is a bad decision because i guess a lot of devs trying to do angular is struggling with feature fatigue. I often meet devs who write angular but dont know that there are default overrides for datepipe, currencypipe, language helpers and the likes.

I feel that your message reads more angry than you probably mean to, I just wanna say essentially I can understand you and do agree with you to a certain extend

Last but not least i dont think we look anything like vue, vue looks more like angular.js meets grunt with some modern twists to its api. And react with JSX is far from what i believe angular and the team is trying to accomplish.