DEV Community

Cover image for Signals Sub-RFC 3 — New Angular Reactive Approach or a Path to Confusion?
Daniel Glejzner for This is Angular

Posted on • Updated on

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.

Generated by MidJourney AI

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.

Generated by MidJourney AI

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>;
Enter fullscreen mode Exit fullscreen mode

Option 2: “In between”

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

Option 3: RFC proposal

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

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.

Generated by MidJourney AI

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.

Generated by MidJourney AI

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.

Generated by MidJourney AI

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.

Generated by MidJourney AI

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.

Generated by MidJourney AI

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!

Top comments (2)

timcreasman profile image
TimCreasman • Edited

Interesting topic and summary!

I agree with most of these concerns but I believe a lot of them can be solved with decent guidelines and documentation. Angular should definitely take their time here. I also don't think Signals should be viewed as a replacement for RxJS either. Both ideas solve different use cases and can be used in tandem.

Obviously, Signals are not a perfect solution and there will be problems but I'm optimistically excited to see where this carries the framework. Only time will tell!

dinbtechit profile image

Honestly. I not sure singals is a right stratergy. It would be better to embrace RXJS. Or use concepts like coroutines and flow similar to Kotlin. I am not a fan of introducing termonolgies and lingos for the same stuff.