This content originally appeared on Bits and Pieces - Medium and was authored by Daniel Glejzner
Signals Sub-RFC 3 — New Angular Reactive Approach or a Path to Confusion?
Learn about Angular’s Signals API and the concerns about its potential benefits and implications for developers.
There have been a lot of discussions lately within the 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. The Angular team is highly reactive and is adapting the vision based on community response.
Sub-RFC 3: Signal-based Components - concerns
Florian Spier has started a 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 the 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 its 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.
💡 OSS tools such as Bit makes component-driven development with Angular easier by providing an integrated dev environment (compiler, tester, linter, documentation, CI, dev server, and packaging/dependency management/bundler all-in-one) for building apps with Angular. It enables you to quickly set up a dev environment that follows best practices implemented by the Angular team and projects generated by the Angular CLI.
Learn more here:
Build Angular Apps with reusable components, just like Lego
Bit’s open-source tool help 250,000+ devs to build apps with components.
Turn any UI, feature, or page into a reusable component — and share it across your applications. It’s easier to collaborate and build faster.
Split apps into components to make app development easier, and enjoy the best experience for the workflows you want:
→ Micro-Frontends
→ Design System
→ Code-Sharing and reuse
→ Monorepo
Learn more:
- Introducing Angular Component Development Environment
- 10 Useful Angular Features You’ve Probably Never Used
- 11 Top Angular Developer Tools for 2020
- How We Build Micro Frontends
- How to Share Angular Components Between Projects and Apps
- How we Build a Component Design System
Signals Sub-RFC 3 — New Angular Reactive Approach or a Path to Confusion? was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by Daniel Glejzner
Daniel Glejzner | Sciencx (2023-04-14T08:25:31+00:00) Signals Sub-RFC 3 — New Angular Reactive Approach or a Path to Confusion?. Retrieved from https://www.scien.cx/2023/04/14/signals-sub-rfc-3-new-angular-reactive-approach-or-a-path-to-confusion/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.