Signals Sub-RFC 3 — New Angular Reactive Approach or a Path to Confusion?

There have been a lot of discussions lately within Angular community about the cost and implication of forthcoming changes to Angular reactive primitive.

A lot of people can see a bright future but with time more and more developers start to notice potential pitfalls. Angular team is highly reactive and adapting the vision based on community response.

Sub-RFC 3: Signal-based Components - concerns

Florian Spier has started very interesting discussion in Sub-RFC 3 voicing his concerns.

I really fear to see applications which mix everything: Signal APIs, old APIs with decorators, mixing Observables and Signals…

This being a key part, you can see more detailed thoughts in the Sub-RFC 3 discussion section.

Based on that very interesting discussion unfolded involving Angular core Team members.

Three Options for Signal API Integration

In the discussion, Andrew Scott (Angular core team) presents three options for integrating the Signals API:

• Preserve the current decorator-based syntax for compatibility.

• Transition to a new syntax but maintain backward compatibility.

• Fully embrace the new syntax and patterns, disregarding the old ones.

Option 1: “Least change”

@Input({alias, required, initial: X}) prop!: Signal<string|undefined>;

Option 2: “In between”

@Input({alias}) prop = input('', {required});
@ViewChild() vc = viewChild('x', {read: ViewContainerRef});

Option 3: RFC proposal

prop = input('', {alias, required});
vc = viewChild('x', {read: ViewContainerRef});

Developers in the discussion mostly favoured option 3, which emphasises the importance of making the right choices for the new API rather than clinging to old patterns. This would bring us closer to avoiding chaos that could come when we would mix approaches.

Concerns About the Signals API

Despite the general excitement based on the above response from Andrew Scott — still more concerns appeared.

• Possibility of potential confusion between Signals and existing Angular concepts

• Writing concise documentation to guide developers

• Signals might lead to more issues than it solves.

Angular’s “Evergreen” Approach

In response to these concerns, Alex Rickabaugh ( Angular core team) emphasizes that Angular should strive to be an evergreen framework, continually evolving to incorporate new ideas and technologies. This approach ensures that existing Angular developers can benefit from improvements without the need for costly and time-consuming rewrites.

The goal here is very well formed. And by achieving that the framework could finally be stable with it’s core solutions.

Compatibility Between Old and New APIs

Alex Rickabaugh explains that compatibility between old and new APIs is a top priority for the Angular team. Existing components and directives will work with the new signal-based components and vice versa — which clears a lot of confusion in the community.

However, the syntax and internal lifecycle functions may differ between the two types of components.

Critical Reflection on the Signals API

Florian Spier calls for the Angular team to critically examine the risks and benefits of introducing the Signals API. Questions raised include whether it would solve more problems than it causes, if embracing RxJS entirely would be a better alternative, or if it would be possible to make Signals an internal implementation while maintaining a consistent public API using RxJS.

We need to wait and see how all of this unfolds

We have to watch closely and participate in the coming changes using the discussions. Angular Team is very alert and welcomes our input.

While many are excited about the potential improvements - concerns about compatibility persist. The Angular team will need to carefully consider the implications of introducing Signals and ensure that the new API benefits developers without causing unnecessary disruption to the existing ecosystem.

I hope you liked my article!

If you did you might also like what I am doing on Twitter. I am hosting live Twitter Spaces about Angular with GDEs & industry experts! You can participate live, ask your questions or watch replays in a form of short clips :)

If you are interested drop me a follow on Twitter @DanielGlejzner — would mean a lot :). Thank You!