[Watch This Space] Angular Reactivity with Signals

[alxhub]

tl;dr: we've begun some prototyping work around adding signals as a reactive primitive in Angular, in advance of a formal Request For Comments (RFC) which we plan to open soon. Prototyping early and in the open aligns with our team values and allows us to get the most out of an RFC.

If you've seen our talk from ng-conf 2022, Angular: A Design Review 10 Years Later, you know we've been thinking long and hard about some fundamental design decisions of the framework. Last year, we kicked off a long-term research project with an ambitious goal: to embrace fine-grained reactivity in the core of the framework.

In a fine-grained reactive web framework, components track which parts of the application's data model they depend on, and are only synchronized with the UI when that model changes. This is fundamentally different from how Angular works today, where it uses zone.js to trigger global top-down change detection for the whole application.

We believe adding built-in reactivity to Angular unlocks many new capabilities, including:

• A clear and unified model for how data flows through an application.
• Built-in framework support for declarative derived state (a common feature request).
• Synchronizing only the parts of the UI that needs updated, at or even below the granularity of individual components.
• Significantly improved 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.

Changing the reactivity model of an established framework like Angular is a significant project, with numerous challenges. Our plan for this project is broken out into multiple phases:

1. Research and development, experimenting with different approaches to reactivity.
2. Selection of a candidate design.
3. Prototyping of the initial design to demonstrate feasibility.
4. One or more community Requests for Comment (RFCs) to explore tradeoffs and inform the final design.
5. A developer preview of the core reactivity implementation.
6. Iteration and expansion of the core implementation towards the full design.
7. Collaboration with the community to bring the entire Angular ecosystem forward into a reactive future.

Over the last few months, we've progressed through the first and second stages of this project, and have converged on a design based on the well-known reactive primitive of signals. During our experimentation we felt that this design demonstrated the strongest alignment with our overall goals.

Signals are not a new idea in the framework space - Preact, Solid, and Vue all employ some version of this concept to great success. We've taken a lot of inspiration from these and other reactive frameworks, and we are especially grateful to Ryan Carniato of SolidJS for his willingness to share his expertise and experience in many conversations over the last year.

That said, requirements across frameworks differ widely, and we've designed our version of signals to both meet Angular's specific needs and as well as take full advantage of Angular's unique strengths. Even though it's still in the prototype stage, there are a few aspects of our design which we're particularly proud of:

• Lazy evaluation, which is both efficient and avoids the need for explicit batching operations
• A computation model which doesn't require immutable data
• Flexible effect scheduling, allowing for seamless integration with Angular
• Clever use of WeakRef to avoid explicit lifecycle management of signals
• Possibilities around using our compiler to optimize various reactive operations, such as scheduling effects to automatically minimize reflows when performing DOM operations
• Bidirectional integration story with RxJS reactivity

We've begun prototyping this design and will be integrating it into Angular over the next few months. We're committed to our open source spirit and plan to conduct these prototyping efforts in the open. This prototyping is essential to proving that our design for signals in Angular is viable and allows us to progress to a community RFC. The RFC will cover the rationale for using signals and the detailed design of various parts (our implementation, integration with RxJS, and other topics related to this effort).

We strongly believe that adding built-in reactivity to Angular is in the long term best interest of the framework and its users, and look forward to sharing more information about this project in the upcoming RFC.

FAQ

When will the RFC be?

Sometime later this year, depending on how smoothly the prototyping efforts progress.

Why signals as the reactive primitive?

This is a great question, and one which will be thoroughly discussed in the upcoming RFC. In short, signals have many of the properties we identified as desirable in a reactivity system designed for Angular, including:

• Values that are always available (synchronously)
• Reading a value does not trigger side effects
• Consistency between values (reads can't show inconsistent state)
• Implicit, low overhead subscriptions
• Automatic and dynamic tracking of dependencies

Why are you committing code before the RFC?

There are a few reasons why we've chosen to begin prototyping before opening an RFC:

1. We feel having a real prototype will amplify the value we can gain from an RFC, as we will be able to share more detailed designs and ask more precise questions.

2. In any major design, there are challenges and constraints which only become visible at the scale of a full prototype. We want to uncover these and account for them in the RFC itself.

3. Many technical problems are unrelated to the overall reactivity system design (such as how it will integrate into Angular's change detection algorithm). We want to tackle these problems sooner rather than later.

4. Google's internal codebase has a different set of build tools and constraints than the external ecosystem, and early prototyping is necessary to validate our designs in that environment as well.

[mephistorine]

I advise you to take a look at the following signal implementations: artalar/act, nanostores/nanostores.

[pavankjadda]

Amazing. Can't wait to see the prototype 😃

[JosefBredereck]

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.

[jnizet]

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.

[pavankjadda]

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

[chen-yangfan]

So, can I remove zone when I use Signal？

[michaelfaith]

@chen-yangfan yep! That's the goal

[nartc]

Thank you for the transparency. I've taken a look at the code and "WOW!". This specific test puts a smile on my face.

[damianstasik]

Here are a few libraries you may find interesting for the prototyping phase: https://github.com/damianstasik/awesome-reactivity

[alxhub]

I hope we'll one day make the list!

[Lonli-Lokli]

I would also add Effector to the list https://github.com/effector/effector

[e-oz]

I do not like dirty functions (functions with the internal state, AKA “hooks”), I think that functions should be pure and for keeping the state we have class instances.

So, the fact the “hooks plague” is corrupting Angular is bad news for me, but if it will help us to get rid of zone.js - amazing. Because zone.js is much worse.

[mfp22]

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

[bryanerayner]

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

I'm not seeing the downsides here

[marcus-sa]

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.

[mfp22]

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

[e-oz]

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

[haskelcurry]

So basically after 7 years of development you figured out that RxJS is "doesn't fit all the needs" huh?
Let me guess, after you release these Singals, you'll rewrite the Engine "based on our brand new Signals system" ™️
How about focusing on the real things, like make HMR work in 2023? #39367

[haskelcurry]

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

[EnricoVogt]

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.

[michaelfaith]

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

[twerske]

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

[marcus-sa]

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

[davidivkovic]

Angular is the best framework

[tayambamwanza]

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

[davidivkovic]

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

[tayambamwanza]

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

Thanks for answering my question

[pkozlowski-opensource]

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

[Harpush]

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.

[michaelfaith]

Exciting development. Thanks for all the work and for the team's transparency along the way.

[HCenggel]

I hope it will not have too much impact on the existing development model.

[haskelcurry]

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.

[lazybobcat]

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.

[michaelurban]

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

[fastAstortoise]

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

Awesome!
Maybe the mental model behind the signals can implement the InteropObservable type to build the bridge between rxjs and signals, translating between both will ease!

[SanderElias]

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

[menosprezzi]

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

[timonkrebs]

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

[GabrielBB]

wou, what @menosprezzi said is interesting

[dvalentine314]

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

[IRod22]

I kinda want to stress-test this RFC with some questions that the Angular team may want to consider:

1. How will affect RxJS and the Angular ecosystem? Many libraries and frameworks rely on both Angular and Rx together, so replacing the reactivity system will be a major blow to RxJS and possibly the entire Angular community.
2. How will this affect Angular itself? For instance, @angular/common/http heavily relies on RxJS, so this RFC may need to consider how much of the core API needs to be changed.

Those are just some questions I can think of at the moment, and I'll update this comment when I think of more questions. I am sorry being a pessimist with this RFC, and I am not trying to shoot this RFC down; however, RxJS is a critical part of Angular, and replacing it will cause millions of websites to break if this RFC is not handled carefully. If this RFC goes through, I would suggest creating an extended LTS version or a compatibility mode, so websites have a good window of time to migrate before the pre-RFC versions sunset.

[e-oz]

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.

[IRod22]

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

[haskelcurry]

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.

[fastAstortoise]

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

[SanderElias]

#49090 (reply in thread)

[BruceWeng]

Thank Angular team! I have been watching the progress of optional zone for many months. It is fantastic to adopt signal fine-grained reactivity to Angular core. Will the signal be able to run outside of component like Solidjs? If it does, that will be super helpful to reuse/organize many common logics.

[SanderElias]

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

[tienthanhjlw]

wow congratulations 🥳🥳

[Harpush]

Should be a great addition! I guess it might change how we look at state management. Is there any thought how signals can enhance state management? Or maybe even a native angular solution?

[pkozlowski-opensource]

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

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

[robounohito]

the problem with that is that you just can’t see code organization as a problem. You’re talking about attacking “real” problems, get things done. Quickly. Forcefully. But it’s not how the reality is. 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. And this state is what they call "referential transparency”, keeping everything in pure functions. Or FP. And when you see reality in this light you will see that this “pure” code organization will also lead you to “correct” implementations of your problems. Not the other way around. (But yeah, I’m talking about real programming, not about those cases when you just every time rewriting everything from scratch in what fashionable at the moment manner)

…

On Mar 10, 2023, at 5:07 PM, Timon ***@***.***> wrote: Are we now philosophers? Is it really a discussion about signals in angular anymore? I think there are real world apps that are roughly at this level of complexity and for that I would consider anything that is not straight forward to implement over engineered. Since I am interested in how it is practical in the real world. — Reply to this email directly, view it on GitHub <#49090 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMUAE6Q2WXJPIDULO6Z54DW3M7UJANCNFSM6AAAAAAU5H2RGI>. You are receiving this because you were mentioned.

[timonkrebs]

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.

[Harpush]

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

[timonkrebs]

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

[Harpush]

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

[robounohito]

I'm just replying to comments in my email. It says “ Reply to this email directly”. So I do. but ok, I think I made my point. I will probably unsubscribe now as this will not lead to anything and not exactly interesting to me anymore

…

On Mar 10, 2023, at 5:16 PM, Clara Castillo ***@***.***> wrote: @robounohito <https://github.com/robounohito> it's really hard to follow a discussion if you make a new comment every single time. Just reply directly to the comment you want to anwer to... Now the whole thread is cluttered... — Reply to this email directly, view it on GitHub <#49090 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMUAEZEJDLUXMTOLGQNXRLW3NAWRANCNFSM6AAAAAAU5H2RGI>. You are receiving this because you were mentioned.

[timonkrebs]

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

[mfp22]

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