[Complete] RFC: Angular Signals🚦

[atscott]

RFC: Angular Signals

Authors: @alxhub, @atscott, @dylhunn, @jelbourn, @pkozlowski-opensource
Area: Angular Framework
Posted: April 3, 2023
Status: Open

(this is the main RFC document, which links to the others)

We teased this in February, and now it's time to dig into the details: the Angular team requests your comments on our plan to adopt signals as a reactive primitive for Angular.

Before you dive in

Background context

Before going further, it's helpful if you understand How Angular change detection works today.

What kind of feedback are we looking for?

While we're excited to hear any and all comments on Angular Signals, we have additionally called out specific discussion points throughout the RFC for directed feedback. When you leave a comment, be sure to note the open question(s) to which you're responding.

As always, keep our code of conduct in mind. We know that a proposal of this scope significantly impacts Angular and the way you use it in your projects. We appreciate your commitment and investment in this project and ask to keep comments respectful. Remember, we are all just folks doing our best with limited resources.

How this RFC is organized

Because Angular Signals is a large project, we've split this RFC into several smaller docs. We recommend first reading the overview in this document and then jumping to the more specific docs in order.

Goals

This is a big change to Angular, so it's important to talk about why we're choosing to take this step. As we began our investigation into reactivity, we set out several goals we wanted to achieve that we felt would greatly improve Angular, based strongly on developer feedback over the last few years:

• Angular has a clear and unified model for how data flows through an application.
• The framework has built-in support for declarative derived state (a common feature request).
• Only the parts of the UI that need updating should be synchronized, at or even below the granularity of individual components.
• Smooth interoperability with reactive libraries such as RxJS.
• Better guardrails to avoid common pitfalls that lead to poor change detection performance and avoid common pain points such as ExpressionChangedAfterItHasBeenChecked errors.
• A viable path towards writing fully zoneless applications, eliminating the overhead, pitfalls, and quirks of zone.js.
• Simplification of many framework concepts, such as queries and lifecycle hooks.

We think the best way to achieve our listed goals is to add fine-grained reactivity to the framework with Signals.

An RFC in four parts

If you're interested in the choice of signals as the reactive foundation of the framework, see the sub-discussion RFC #1: Signals for Angular Reactivity.

If you want to discuss our signal API and implementation itself, see RFC #2: Signal APIs.

If you're interested in exploring how using signals will look in Angular, then start with RFC #3: Signal-based components.

And finally, if you're curious about interoperability with RxJS, see RFC #4: Observable and Signal Interoperability.

Wrapping up

That's it!

This RFC has been a long time in the making. We're excited (and relieved) to finally share the details. Whether you're a long-time Angular developer or just stopping by to check out this new buzz on Angular, we're looking forward to obsessing over your every comment.

We want to make a special thanks to all of the hard work and innovation that have inspired us in the web community. Signals are clearly having a moment in the discourse today. Our ideas build on top of a large body of work– Preact, Vue, and SolidJS in particular have been inspirations for this project.

Frequently asked questions

Is this change going to be backward compatible?

Absolutely! Backward-compatibility is non-negotiable and we do everything to assure that the existing applications and libraries continue working as-is, without any modification. This is a gradual, opt-in change.

Is this another Angular rewrite?

No! This is mostly an additive change with some deeper modifications to the change detection algorithm. We take backwards compatibility seriously, and validate all changes with both our own suite of comprehensive tests and against the tests of thousands of Google applications built with Angular.

Is Angular getting less opinionated?

It's true that recent (and upcoming) changes to Angular have introduced new ways of building Angular applications. Most notably this includes standalone components and now signals. We introduce these new approaches over time to evolve the framework based on community feedback and our own observations of Angular in the wild. Our commitment to maintaining backwards compatibility means that the ecosystem ends up supporting multiple ways of doing things.

The result isn't that Angular is less opinionated, but instead that the opinions change over time. Typically, the most recent features represent the way we think most Angular developers should build their apps. We will always clearly communicate the preferred approach and update documentation / tooling accordingly. At the same time, the old way of building will live on for backwards compatibility (following our support policy).

Why are you working on signals and not feature XYZ?

In any popular framework there are always more features requested than we have bandwidth to work on at any given point in time. We are always focusing on projects that are the most helpful and impactful given the long-term evolution and stability of Angular. Signals are one of those projects.

First of all, improved runtime performance and optional zone.js was on our public roadmap for quite some time. Signals allow us to tackle this item.

More importantly, reactivity is at the very heart of a model-driven UI framework. By rethinking change detection, we open doors to simplification and evolutions that were not possible before. Faster performance, better forms, improved state management, and streamlined authoring format are prominent examples.

By baking-in reactivity into the framework we introduce primitives that the community can build upon.

Having said all this, the work on reactivity does not stop the work on the other important framework improvements. As an example, Angular v16 introduces the improved hydration, required inputs and tons of other improvements. We will continue working on other roadmap items while the reactivity work is in progress!

Appendix: How Angular change detection works today

Angular was built on the idea of a declarative, model-driven UI. Your application state is the source of truth and the framework automatically updates the page based on model changes. You declaratively express the mapping of model to UI via an HTML-like template. To keep the page up-to-date, the framework must track model changes over time.

zone.js

Angular uses zone.js to track various events in a browser (ex. DOM events, network requests and timers). Zone.js tracks these events by monkey-patching (wrapping and patching a callback function at runtime) any API that might lead to an application model change. When such an event occurs, however, Angular does not have any information as to what specific changes have occurred, or even if there were any changes at all.

Upon receiving event notification from zone.js, Angular will read (pull) new model values and update UI based on diffing the previously seen model values.

This approach provides excellent developer experience for small and simple applications:

• You can use plain JavaScript data structures
• Your state can live anywhere
• You can mutate your state any way, any place (no need for setState or similar APIs)

In practice, however, large applications often grow to see zone.js become a source of performance issues and developer-facing complexity. As the web platform continues to grow and evolve, it also represents a rising maintenance cost for the Angular team.

While zone.js provides the mechanism that tells Angular when to run change detection, the next section discusses what this change detection entails.

Global, top-down change detection

Angular's default strategy is to run change detection over the entire component tree to make sure that the DOM reflects the most up-to-date model. Because Angular has no information about which parts of the application state have actually changed, it must check everything. In practice, however, only a fraction of the entire application state changes and only a handful of components need to be re-rendered.

Unidirectional data flow

Angular's change detection was designed to refresh application state once. The change detection process starts from the root of the component tree and walks all components down to the leaf nodes.

A single refresh traversal is sufficient if and only if components don’t modify the state of any of their ancestors after they have been visited. Unfortunately, the framework provides several convenient APIs to mutate state exactly in this way mid-traversal.

The component tree matches the rendered DOM tree, which means that change detection traverses the application in rendering order. However, several common web interaction patterns roll up descendant node states into ancestor nodes (e.g. form validity is computed as a function of descendant control states). This leads to the most "popular" error in Angular - ExpressionChangedAfterItHasBeenCheckedError.

OnPush

Angular developers can optionally configure change detection to only run on a subset of the component tree using the OnPush strategy. Components configured as OnPush and their descendants are checked for changes only under specific conditions:

• A browser event originated in a component in question
• One of the component’s @Input()s changed as a result of a template binding
• A component was explicitly marked for check

While the OnPush strategy can reduce some of the performance cost, this strategy is limited:

• Because OnPush components prevent their descendants from being checked, descendent components that depend on global state may not correctly update if they depend on global state outside of their ancestor components.
• Because change detection always starts from the application root, running change detection on an OnPush component additionally checks every component between that component and the root, limiting the value of the optimization.

RxJS integration

You might notice that none of this overview includes RxJS. Angular does not internally use RxJS to propagate state or drive rendering in any way. Instead, Angular uses RxJS as a convenient data structure to express streams of events over time (such as for EventEmitter), completely disconnected from the change detection and rendering system.

[lukaesch]

What impact will Signals have on hydration and server-side rendering improvements that are both on the roadmap?

[atscott]

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?

[jessicajaniuk]

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.

[AndriiDidkivsky]

Why decorators are magic for devs? Why perfectly designed class components should be replaced with some "react style" hooks?

Looks like angular has lost it's popularity and you are trying to return back peoples attention. I really consider that react hooks are mess.
Angular was such a great framework for big projects with a lot of bussness logic that noone of vue or react can handle properly. Without awful ngrx, angular is such a great instument, why should I use "that", "that" you've just inroduced to us? I really do believe that I'll get it, but if i don't understand react hooks, i'll never understand this.
I think of using Ember (,:

[AndriiDidkivsky]

@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.

[Coly010]

^ I don't hate that tbh.

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

[e-oz]

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

[gioragutt]

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.

[dionatan-g]

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

[AlDrag]

With a Zoneless application using signals, will this negate the need to trigger change detection when writing unit tests?

Writing unit tests for OnPush components by wrapping them in a host component is a common pain point for me. If going Zoneless with signals solves/simplifies this, that'll be amazing!

[atscott]

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.

[kyjus25]

Will a zoneless application using Signals offer bundle size improvements over a zoneful one, or are they marginally the same?

[alxhub]

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.

[danqulogy]

Interesting times ahead for #angular 😁

[ts-dot-rs]

The comeback we never knew we needed #bing

[michaelfaith]

Really appreciate the thoroughness and thoughtfulness of this RFC. Look forward to digging into the sub sections. But, overall, I'm excited for this development in the framework, especially with regard to its impact on performance, and enabling teams to create more performant components without having to hand-hold change detection so much. Eager for a zoneless future.

[MahmoudTarek44]

I'm curious how using signals as a reactive base for Angular will affect a part such as "Reactive forms module",
And moving forward to use more functions than using classes I think it will change many things in a good way.

[dylhunn]

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.

[mikeandtherest]

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

[DibyodyutiMondal]

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.

[AbozahraOsama]

I'm wondering how will the use of Signals affect Angular’s internals that depend on observables such as forms, router, and http client?
Is it going to be rewritten to use Signals internally?

[Coly010]

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

[Armenvardanyan95]

I think this will also pave the way to having functional components in the future. It is very understandable, and I imagine a component built entirely on signals would be way more readable and simple than a "traditional" one.

[timonkrebs]

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/

[lvetskov]

Breaking changes of this scale will not only attract people - they will move people away. Angular, once again, will look like a non-reliable framework 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 frameworks 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.

[Jordan-Hall]

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 framework migrations

[elgreco247]

@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"?

[michaelfaith]

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).

[swami-sanapathi]

It's better to have some code snippets of signals with each use case in docs.

Signals are beast 😍 loved it. Appreciating your hard work @atscott @alxhub @dylhunn @pkozlowski-opensource @jelbourn

[jrista]

[timonkrebs]

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...

[kyjus25]

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.

[michaelfaith]

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.

[timonkrebs]

@jrista supporting a class-based or functional approach. What does that mean, from an overall complexity standpoint, at the whole framework 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.

[kyjus25]

Is OnPush directly correlated to ZoneJS, or are they separate entities? More specifically, can I utilize a library using OnPush and still be able to remove zone.js from my application running Signals?

[atscott]

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.).

[ysk3a]

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)

[atscott]

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.

[johncrim]

I think this is the most exciting evolution of Angular since 1.0, and the evolution since 1.0 has been solid. I'm extremely happy with the overall design, and what it unlocks for Angular going forward - namely clearer code and performance. Kudos to the team members leading this effort for the thoroughness of these RFCs and the prior work to refine the concepts and ensure backward compatibility in the design.

I've always felt that zone.js and the change detection model was the worst/clunkiest part of Angular - to clarify, zone.js is an impressive building block, but it and the change detection model are the hardest parts to understand and troubleshoot. In addition to potential hidden efficiency problems, there are unintuitive rules - eg change detection doesn't propagate unless inputs have changed or a DOM event has occurred; and host attribute/style changes require a change detected on the parent. It requires regular developers to have a deeper understanding of the internals of Angular than it should. So I've avoided relying on zone as much as possible, use OnPush or ChangeDetectorRef.detach, and come up with my own pipes and primitives for understandable and more granular updates in performance sensitive cases.

Hindsight is 20/20, but it's clear to me that this is the "correct" approach for Angular, and is needed to make/keep Angular competitive with newer frameworks.

[theophane-girard]

HI :) got this error while using fromObservable: "ERROR Error: fromObservable() signal read before the Observable emitted"

I have to add a startWith as a workaround. Is this an on-purpose behavior?

isNewChange$ = this.form.controls.isNew.valueChanges.pipe(
    // startWith(this.form.controls.isNew.value),
    tap(console.log)
);
isNewChange = fromObservable(this.isNewChange$);

[e-oz]

yes, unfortunately. see RFC#4.

[theophane-girard]

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

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

[KevTale]

Awesome works from you folks! 🔥

Do you already have some vision on the long term plans? I mean, are you aiming (in a future version like 18 or 19 or 20...) to make signal based components by default (and standalone as well) which will imply the deprecation of input/output decorators and ngOnInit and other lifecycle hooks.

I'm asking that because as the primary goal of what's coming since v14 is to reduce the learning curve and increase the traction I guess new comers will get confused if both worlds (signal based and zone based components) are living together in the framework, I'm afraid some developers might get discourage when asking themselves "should i go signal based or zone based" which will requires a lot of digging to understand the pros and cons (thus the learning curve will stay the same).

I'm a fan of opinionated technologies and I hope Angular will stay opinionated and that we are currently in a transition to full standalone and signal based apps. 🫶

[tronicboy1]

Great work guys! I've played around with signals and I think you're getting it right. It feels like the good parts of Vue.

One thing I thing we could do better is the value calls on primitives.

1. At the very least it would be great if we didnt have to add () in the template to get Signal values.
2. It would be even better if we could figure a way to avoid value calls this.count() in computed callbacks.

Could this be possible with primitive values?

class WritableSignalPrimitiveConversionImpl<T> extends WritableSignalImpl<T> {
  [Symbol.toPrimitive](hint: string): T {
   switch (hint) {
      case 'string':
         return String(this.value);
      case 'number':
         return Number(this.value);
      default:
        return this.value;
   } 
 }
}

Sorry very rudimentary idea but maye using Symbol.toPrimitive could get the desired API?

[wizardnet972]

How about using objects inside a signal? What do you think about it? can I use it? angular will support such a thing?

user = signal<User>({ name: '..', ... });

When I change name property does angular know about that? or is it just a solution for primitive type (number, string, boolean..)?

@alxhub @pkozlowski-opensource

[mfp22]

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.

[mlc-mlapis]

@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.

[michaelfaith]

It would be something similar to

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

which would tell Angular the signal changed

[mlc-mlapis]

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.

[alxhub]

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.

[retry2z]

Is there a way to implement the signal change detection into the async pipe?
We got the view where is used and we got the subscription to track.

[alxhub]

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

[retry2z]

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

[DibyodyutiMondal]

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?

[mlc-mlapis]

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.

[DibyodyutiMondal]

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?

[lifaon74]

This feels like, we're reinventing the wheel... I mean: Angular is and was built to be reactive. The original idea was to use RxJs's Observables to mutate the DOM, when an Observable changes. And it can actually be done, when using for examples Stores or developing in reactive programming.

Signals are reactive programming but with a different syntax. More precisely, they are BehaviorSubject.
So, if I had to guess, we'll see soon a tons of pipes/functions to play with Signals in React, and we'll encounter the same in Angular. BUT all of this already exists in Angular, simply using RxJS... We'll end up with 2 Observable like libraries in the same framework. This sounds like craziness, all of this due, in my opinion, to an unjustified "hype train".

Maybe we should let the things settle down, and provide a very robust paper: why Angular should move to Signals ? Are the benefits really worth it ? Are they other solutions, maybe better ?

I mean, Angular is a widely used framework, mainly by companies requiring a stable, scalable, and robust framework. So we should not be blind, jumping from the latest trend just to attract "the cool kids". Angular's target should remain to focus on companies requirements, not on the "fun" and "latest" tool. They may be great, but they should not interfere with a long term vision.

[lifaon74]

@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.