Sub-RFC 3: Signal-Based Components — A Closer Look at the Concerns
Recent discussions in the Angular community have centered on the potential consequences of introducing Signals as a new reactive primitive. While many see a promising future, an increasing number of developers are beginning to identify possible downsides. The Angular team remains attentive and is actively adjusting its approach based on community feedback.
Sub-RFC 3: Signal-Based Components — Open Issues
Florian Spier initiated a thought-provoking conversation within Sub-RFC 3, raising a clear worry about the future state of Angular applications.
What I truly dread is seeing applications that combine everything: Signal APIs, traditional decorator-based APIs, and a mix of Observables and Signals…
This central concern is elaborated upon in the Sub-RFC 3 comments section.
That initial post sparked a significant dialogue with participation from Angular core team members.
Three Paths for Integrating the Signal API
In that conversation, Andrew Scott (Angular core team) outlined three potential strategies for bringing the Signals API into the framework:
Maintain the existing decorator syntax to ensure compatibility.
Introduce a new syntax while continuing to support the old one.
Adopt the new syntax and patterns wholeheartedly, moving away from the legacy approach.
Option 1: Minimal Alteration
@Input({alias, required, initial: X}) prop!: Signal<string|undefined>;
Option 2: A Middle Ground
@Input({alias}) prop = input('', {required});
@ViewChild() vc = viewChild('x', {read: ViewContainerRef});
Option 3: The RFC Proposal
prop = input('', {alias, required});
vc = viewChild('x', {read: ViewContainerRef});
The community response in the discussion leaned heavily toward option 3, underscoring the need to prioritize the integrity of the new API over preserving older paradigms. This approach is seen as a way to prevent the disarray that could arise from combining incompatible styles.
Apprehensions Surrounding Signal APIs
Even with the encouraging response from Andrew Scott, new worries emerged alongside the initial optimism.
Potential confusion between Signals and already-established Angular concepts
The need for clear, comprehensive documentation to steer developers
The risk that Signals could create more problems than they resolve.
The “Evergreen” Philosophy of Angular
Addressing these doubts, Alex Rickabaugh (Angular core team) points out that Angular should aim to remain an evergreen framework, consistently progressing to integrate new ideas and technologies. This strategy allows existing Angular developers to take advantage of enhancements without undergoing expensive and time-intensive migrations.
This objective is clearly defined. If realized, it could bring the framework toward a state of stability at its core.
Interoperability of Legacy and Novel APIs
Alex Rickabaugh clarifies that ensuring a smooth coexistence between old and new APIs is a critical priority for the Angular team. Current components and directives will continue to function alongside new signal-based components, and the reverse is also true — a clarification that has resolved considerable uncertainty.
Nonetheless, the syntax and internal lifecycle mechanisms could vary between the two component types.
A Critical Examination of Signal APIs
Florian Spier urges the Angular team to carefully weigh the risks and advantages of introducing Signals. Key questions have been posed, such as whether the new API would resolve more issues than it introduces, if fully committing to RxJS might be a superior path, or if Signals could be kept as an internal detail while RxJS continues to serve as the public interface.
Awaiting the Resolution
It is important to remain engaged and follow the ongoing discussions as these changes take shape. The Angular Team is highly responsive and encourages community participation.
While a significant portion of the community feels optimistic about the anticipated improvements, worries regarding compatibility continue to be voiced. The Angular team must carefully evaluate the effects of adding Signals and make certain that the new API provides clear benefits to developers without causing avoidable friction within the existing ecosystem.
If you found this helpful!
I also share Angular content and host live events on Twitter, featuring conversations with GDEs and industry professionals. These sessions offer a chance to engage directly, ask your own questions, or view short clips from previous discussions.
If that sounds interesting, feel free to follow me on Twitter at @DanielGlejzner — your support is much appreciated. Thank you!