[Complete] Sub-RFC 1: Signals for Angular Reactivity

[alxhub]

Sub-RFC 1: Signals for Angular Reactivity

This discussion covers the choice of Signals as a new reactive primitive for Angular, and discusses several alternatives considered.

Why a new reactive primitive?

In a model-driven web application, one of the main jobs of the framework is synchronizing changes to the application's data model and the UI. We refer to this mechanism as reactivity, and every modern web framework has its own reactivity system.

Today, Angular's reactivity relies on the zone.js library. Reactivity with zone.js has both unique benefits and unique challenges, which are discussed in more detail below (see: Why not continue with zone.js?). Crucially, zone.js does not provide "fine-grained" information about changes in the model. Zone.js is only capable of notifying us when something might have happened in the application, and can give no information about what happened or what has changed.

In order to achieve our main goals (see: top-level RFC goals) we'll need to introduce a new reactivity model to Angular, with capabilities beyond what can be achieved with zone.js. This means adding a new primitive to the framework which can provide fine-grained information about model changes. A major design goal of Angular Signals is to make the integration of these two reactivity models as seamless and straightforward as possible, so developers can concentrate on shipping features instead of reasoning about how change detection is going to work in their applications.

Requirements for a new reactivity primitive

Before deciding on a new reactivity approach, we set out some requirements - properties that we would like the new reactivity solution to have:

• It must be able to notify Angular about model changes affecting individual components (per overall goals).
• It must provide synchronous access to the model, because template bindings must always have a current value.
• Reading values must be side-effect free.
• It must be _glitch fre_e: reading values should never return an inconsistent state.
• Dependency tracking should be ergonomic.

Discussion point 1A: are there other requirements we should consider?

Options considered

We experimented with a number of different alternatives, including:

• Improving zone.js
• setState-style APIs
• Signals
• RxJS
• Compiler-based reactivity
• Proxies

Choice of signal-based reactivity

During our research, one reactivity model stood out as clearly meeting our requirements while offering a very natural developer experience: signals. Signals are not a new idea in the framework space - Preact, Solid, and Vue all employ some version of this concept to great success.

So what is this primitive?

Signals

A signal is a wrapper around a value, which is capable of notifying interested consumers when that value changes. There are different kinds of signals.

Some signals can have their value directly updated via a mutation API. In our implementation, these are known as "writable" signals. Updates to the model are always done by changing one or more writable signals.

Because reading a signal is done through a getter rather than accessing a plain variable or value, signals are able to keep track of where they're being read. And because mutations are always done with the mutation API, signals can know when they're mutated and inform previous readers about the change.

Computed

A computed signal has a value which cannot be changed directly, but which is derived from the values of other signals.

Example of Signal and Computed

A good example of these two signal flavors working together is a counter numeric value and a boolean isEven flag which tracks whether the counter is even. We could model the counter as a writable signal and increment or decrement it directly. isEven is best modeled as a computed signal, since its value is determined by the value of the counter and should not be updated directly.

Effects

Signals are useful because they can notify interested consumers when they change. An operation that's performed when the signals it depends on are changed is called an "effect". For example, Angular will use an effect to update a component's UI whenever any signals read within that component's template are changed.

Automatic Dependency Tracking

A cornerstone of our signal system design is that when computed signals and effects run, they keep track of which signals were read as part of the computation or effect function. Knowing the dependencies allows the signal system to re-run the computation or effect function automatically whenever any signal dependencies change.

Why is this a good fit for Angular?

Signals as a reactive primitive meet all of the above requirements:

• The framework can track which signals are accessed in a given template, giving us fine-grained information about which components are affected by a given change to the model.
• Signals allow synchronous access to their values.
• Reading signals can't trigger side effects.
• Modern signal implementations are glitch-free and don't expose inconsistent states to the user.
• Signal implementations can track dependencies automatically.
• Signals can be used anywhere, not just in components, which plays well with Angular's dependency injection system.

Additionally, we see a number of additional benefits of signals:

• Computed signals can be lazy and only recompute intermediate values on demand.
• There are relatively few concepts for developers to learn.
• They are easily composed with other reactivity systems, including RxJS and Angular's current zone-based reactivity.

Of all the alternatives explored (see below), our conclusion is that signals are the best fit for Angular and will allow us to meet (and in some cases exceed) our overall goals.

Integration with Signals

So how will Angular make use of this new reactive primitive?

Signals will affect many areas of the framework, especially including:

• Data flow and model synchronization
• The change detection process
• Component lifecycle
• Reactive values produced by the framework (ex. @Inputs)

In this section, we'll dig into how signals will fit into Angular's component model.

Zones are here for the foreseeable future

It's important to recognize that we won't be able to replace zone.js with signals transparently under the hood. Zones and signals are based on fundamentally different assumptions about how data flows through an application, and a component written with zone.js in mind will likely not function without it. We may be able to provide some assistance in migration through tooling, but it will not be completely automatic.

That means for most applications, the new signal-based reactivity will need to coexist and interoperate with existing zone-based reactivity for the foreseeable future.

Signal-based components

We're introducing a new type of signal-based component, which uses signals for its reactivity and rendering. Both the new signal component and existing zone-based components will be able to use and interact with each other in the same application.

Using components as the boundary between reactivity systems will allow application developers to gradually opt-in to signal reactivity in an existing application, and allow library authors to convert their libraries to use signals in a backwards-compatible way.

Note: while this section is written mainly talking about components, almost all of the topics here apply equally to directives.

Local change detection

One significant new capability that signal-based components will have is local change detection. Unlike zone.js, signals give fine-grained information about which parts of the model have changed, signal-based components do not participate in the global change detection. Instead, Angular understands which signals are used in different parts of the component's template, and only synchronizes that component with the DOM when a signal changes.

This is the golden rule of signal components: change detection for a component will be scheduled when and only when a signal read in the template notifies Angular that it has changed.

In fact, in our current design this change detection will happen independently for each view within a component.

Aside: Angular's "View" concept

"Views" in Angular are static fragments of templates - sets of known UI elements, directives, and child components. Views are composed together to create templates that can express conditional or repeated sections of UIs.

For example, the following component template is a single view:

<div>
  <label>Who: <input name="who"></label>
  <label>What: <input name="what"></label>
</div>

Whereas this template has two views - the outer DOM with "Who" and "What", and an embedded view which is conditionally shown which contains "Why":

<div>
  <label>Who: <input name="who"></label>
  <label>What: <input name="what"></label>
  <ng-container *ngIf="showWhy">
    <label>Why: <input name="why"></label>
  </ng-container>
</div>

Each branch of an NgIf or NgSwitchCase and each row of an NgFor are examples of independent views in Angular.

Granularity of local change detection

The choice of per-view change detection is an important one, as there's an entire spectrum of granularity with which we could track changes to the model and update the DOM:

• Entire application: processing the whole application at once (what zone.js does, with the exception of OnPush optimizations).
• Component tree: traversing individual subtrees (an individual component and its children)
• Individual components: checking a component (including all of its views) but not its children
• View: checking each view individually
• DOM element: updating all the bindings for each DOM element individually (text nodes, elements, etc. SolidJS works at this level)
• Binding: updating each DOM binding individually

So why check per-view and not update individual bindings? Would that not be faster/more efficient? The tradeoffs here are not so clear-cut, and while we are interested in exploring designs with more granular updates in the future, there are a few reasons why we believe per-view checking is the best option for Angular's signals today.

1. Dependency tracking has overhead.

Setting up the dependency graph is not free. Our signal library is fast, but the more granular the tracking, the more nodes in the graph need to be allocated and bookkept. This not only takes time, but consumes memory. We have to weigh this cost against the potential benefits of increased granularity.

2. Checking individual views delivers most of the benefit already.

Views are typically small fragments of UI with a manageable number of bindings. The cost to evaluate and change detect a small set of bindings is already very low (remember, Angular does this today for entire applications).

The most expensive components to process with change detection are often those with large, repeated, highly dynamic structures, such as data tables with hundreds or thousands of rows. Such components are naturally already broken down into many individual views (remember, each row is at least one view, maybe more). With view-based change detection and a properly structured model, signals can already be used to drive updates only to one row of the table without needing to process other unchanged rows.

3. View-based change detection with signals composes nicely with zone-based change detection.

The operation of running change detection against a view is already the main primitive on which the existing zone-based whole-application change detection system is built. Using the same granularity for signals makes the interoperability story much more straightforward, and allows the two reactivity models to share most of their underlying implementation code. This will allow us to introduce signal reactivity without greatly impacting bundle size.

@inputs are signals

In signal-based components, inputs will be signals! This choice is directly aimed at the goal of having a clear, unified model for how data flows through an application.

Signal-based inputs have a major impact on data flow, because they work as computed signals, and not change-detected expressions.

Aside: Inputs in Angular Today

To understand the difference in how signal-based inputs work, it's useful to consider in more detail how inputs work in zone-based applications today.

In a zone-based application today, inputs are set during change detection. Let's say the HomePageCmp has the following template:

<user-profile [userData]="authService.loggedInUser.data" />

Suppose the loggedInUser changes. zone.js will notice something happened but doesn't know what specifically changed, and will trigger change detection for the whole application. Change detection will process the HomePageCmp and re-evaluate the binding to [userData]: the expression authService.loggedInUser.data. It will set the UserProfileCmp.userData field to the new value, before descending into the UserProfileCmp and evaluating its template, which might make use of the userData.

Signal-based inputs as computations

If HomePageCmp and UserProfileCmp were signal based components, the userData input would function very differently. Of course, the binding would have to use a signal for the loggedInUser:

<user-profile [userData]="authService.loggedInUser().data" />

When HomePageCmp is first created, and is creating its UserProfileCmp child, Angular will create a computed signal for the [userData] binding expression: computed(() => authService.loggedInUser().data). This derived signal is then provided as the value for the UserProfileCmp's userData input.

This has huge implications:

Signal inputs resolve before change detection

Updates to the userData input signal happen before change detection, not during.

This is the major difference from zone-based component inputs. With signals, the "model to model synchronization" of propagating changes to userData resolves before Angular starts any UI synchronization.

This eliminates an entire category of data flow challenges faced by zone-based applications:

• ExpressionChangedAfterItHasBeenChecked errors are no longer a risk, because the model is fully synchronized before it gets checked. (A non-deterministic model can still cause such errors, but that's a different problem)
• Data can flow independently of the UI hierarchy, instead of being forced to only flow from parent to child. There's no need for setTimeout or Promise.resolve or other tricks.

Input bindings don't trigger local change detection in the binder

Because userData's binding is provided as a computed signal, none of the views in the HomePageCmp depend on its value. Per the golden rule of signal-based change detection, none of its views will be change detected.

Input bindings don't automatically trigger local change detection in the receiver

Just because UserProfileCmp receives userData as a computed signal does not mean that any of its views will be change detected when userData changes. Per the golden rule, UserProfileCmp will only be change detected if it reads the userData input signal somewhere in its template.

In other words, inputs which aren't actually used in templates don't trigger any change detection in signal-based components.

1. When loggedInUser changes, HomePageCmp does not need to change detect any views.

That's because it never actually reads the loggedInUser() value for itself, it only forwards it as a computation to its child component.

Queries are signals

Like inputs, view and child queries are an example of the framework "producing" a reactive value which represents some aspect of the component model. In signal-based components, queries will also be exposed as signals. This allows components to naturally react to queries changing via computed properties or effects, just like with inputs.

Mixing Signal and Zone Components

It's possible to freely mix signal and non-signal components in the same application. As long as the golden rule of signal component is observed, change detection should function correctly even across these boundaries.

When a signal component provides an input binding to a non-signal component, signal semantics are used to detect when the binding changes, and set the input of the non-signal component, mark it for check if necessary, and run ngOnChanges if needed as well.

When a non-signal component binds to the input of a signal component, a similar conversion happens. During change detection of the non-signal component, the binding is evaluated and, if the value has changed, the input signal passed to the child component is updated.

Caveat: non-signal API issues

Sometimes directives expose APIs for their consumers, via local references or the DI system. For example, NgModel exposes its current value as a public property, accessible via local refs:

<input ngModel #in="ngModel">
<p>You typed: {{ in.value }}</p>

Such APIs may be problematic in signal components, since in.value isn't a signal and can't be used to trigger change detection for signal components, even though it changes as the user types.

Note that in zone-based components though, relying on data from a child like this is hugely problematic anyways. If the reflection of the current value is moved above the <input> declaration, an ExpressionChangedAfterItHasBeenChecked error will result.

For Angular-authored directives, we will revisit their APIs and adapt them as needed to work with signal-based change detection. We would expect community libraries to eventually do the same, but this process will take time.

Zoneless Angular

With signals, it will be possible to build an Angular application without zone.js. Rather than relying on zones for change detection to function, signal-only applications will schedule change detection of individual views directly (likely via requestAnimationFrame or some other browser primitive).

In such an application, it would be an error to attempt to use a zone-based component.

Frequently Asked Questions

Architecture

Will signals lead to zone.js being optional?

Yes, this is one of the driving motivations that led the team to signals.

If you write an application exclusively composed of signal-based components, you will be able to remove the dependency on zone.js.

Is zone-based change detection deprecated or removed?

No, zone-based change detection will remain supported for the foreseeable future. Components that depend on zone.js and/or signals can be freely mixed in one application. An application would have to fully track its model in signals to completely remove dependency on zone.js.

Are we going to have another change detection strategy?

Many applications and teams recommend the OnPush change detection strategy to improve performance. Signal-based components have "OnPush on steroids" baked-in.

In the design proposed here only components that read an updated signal will have to be change-detected. None of its parents and none of its children. One and only one component that needs to display changed data.

Signal based components have all the benefits of the OnPush strategy (and more!) without any of its drawbacks - by default. In this sense we actually remove the very concept of change detection strategy..

What about state management with signals?

Signals are a great primitive for managing state and data flow, but we fully expect that more sophisticated stores and state management solutions will emerge. Dedicated state management libraries can address many development concerns, such as granularity of data, collocating signals with custom update methods, managing effects, composing "stores" etc.

We have no plans to develop a first-party state management solution in Angular itself. The broader Angular community, though, possesses a wealth of knowledge and experience in this area. Some major state management libraries have already started to explore incorporating signals:

• RFC: NgRx SignalStore
• RFC: Signals in NGXS
• rx-angular: signal prototypes draft

Why not use RxJS Observable as the reactive primitive?

Observables are a very powerful and flexible primitive for expressing computation in a functional and reactive way. They're used throughout the Angular ecosystem already, often to achieve more fine-grained reactivity than zone.js provides out of the box. For this reason, Observables do seem at first glance to be a natural fit for a new reactivity system for Angular.

We did extensively explore this option, and our conclusion is that while Observables are a powerful primitive, they are a poor fit for template rendering specifically.

Observables are naturally asynchronous

Observables can be used to model both synchronous and asynchronous data flow. However, they don't distinguish these two cases in their API - any Observable might be synchronous, or it might be asynchronous. This duality makes them flexible, but creates issues when using them to model template reactivity.

In an Angular template, bindings always have a current value. For example the property binding:

<input [value]="name">

always provides a value to display inside the <input>. Angular doesn't need to consider the case where the [value] binding doesn't have a value to set yet. If this binding were driven by an Observable instead (let's say name$), then we would lose this guarantee: the Observable may not provide a value synchronously on subscription. In fact it may never produce a value. Angular would therefore need to deal with any binding potentially being in this "pending" state.

This is partly the problem that the async pipe solves. The async pipe always has a value, even if the Observable it's subscribed to has not yet produced a value. Until it does, the async pipe will return null as its value. This behavior is known to be somewhat annoying (requiring patterns like *ngIf="data$ | async as data" to guard against the nulls) and would become even more so if every binding behaved that way, if every input were also forced to be nullable, etc. And null is not the right choice as a "default" for all bindings (text bindings for example would probably want to show an empty string).

We could instead enforce that every Observable used in a template must be synchronous, but this is also an arguably poor experience. Since there is no way to enforce synchronicity through typings, it would need to be enforced with a runtime exception. This could lead to subtle issues if asynchronicity is accidentally introduced deep within an Observable chain, especially if it's only conditionally asynchronous.

Observables are not side-effect free

Another observation (pun intended) is that Observables are often cold and side-effectful. That is, every subscription may potentially trigger arbitrary behavior, up to and including RPCs to backend APIs. This is how HttpClient works: userData$ = httpClient.get('/user') produces an Observable that, when subscribed, will make the backend request to fetch user data.

This is again part of what makes RxJS such a powerful library. The ability to execute data fetching and other expensive tasks on demand allows for very declarative expression of complex data flows, debouncing, retry logic, etc. However, it also leads to issues when using them to drive template rendering. For example, using userData$ in a template will work as expected:

<p>First name: {{ (userData$ | async)?.firstName }}</p>

but if we also try to show the last name:

<p>First name: {{ (userData$ | async)?.firstName }}</p>
<p>Last name: {{ (userData$ | async)?.lastName }}</p>

then we've accidentally caused two backend requests instead of one. This can be addressed with the share or shareReplay operators, but there is no way to enforce this, especially across different components using the same Observable.

RxJS is not glitch-free

This is a much more subtle but deeply important point.

In reactive systems, a glitch occurs when a calculation or reaction observes an intermediate, inconsistent state. As a simple example, consider the counter and isEven example from before. If we write code that logs the message ${counter} is ${isEven ? 'even' : 'odd'} whenever either value updates, then as the counter increments from 0 to 1 we should observe the messages "0 is even" and "1 is odd", but never the message "1 is even". That is, isEven should always be in sync with counter.

RxJS does not provide this guarantee. It's easy to craft an example which shows this behavior:

import { BehaviorSubject, combineLatest, map } from 'rxjs';

const counter$ = new BehaviorSubject(0);
const isEven$ = counter$.pipe(map((value) => value % 2 === 0));
const message$ = combineLatest(
  [counter$, isEven$],
  (counter, isEven) => `${counter} is ${isEven ? 'even' : 'odd'}`
);

message$.subscribe(console.log);
counter$.next(1);

Running this example gives the output which shows the glitch:

0 is even
1 is even
1 is odd

In asynchronous RxJS code, glitches are not typically an issue because async operations naturally resolve at different times. Most template operations, however, are synchronous, and inconsistent intermediate results can have drastic consequences for the UI. For example, an NgIf may become true before the data is actually ready, which could result in reading undefined properties. Or NgFor may briefly observe an empty array and prematurely destroy all rows in a table only to recreate them when the real array arrives, leading to an expensive rerendering.

Conclusion

Because of these incompatibilities with using Observables for template rendering, we decided against using them as the basis for Angular's reactivity. We believe their strength lies in orchestrating complex asynchronous operations, where their flexibility is a big advantage and where computational glitches are not as much of an issue. Therefore, it makes sense to instead invest in interoperability between Observables and the new signal reactivity system. This allows RxJS to be used where it shines, without forcing it to also fit the needs of template rendering.

Signals and RxJS

What about Angular APIs that currently use RxJS?

There are a number of Angular APIs that use RxJS in their API signature(ex. HttpClient, EventEmitter, Forms, Router etc.).

The general plan is to review Angular API surface and selectively convert RxJS usage and / or add signals usage when appropriate. This will not be automatic conversion, though, as RxJS-based APIs might represent two distinct concepts:

• value changing over time - those are perfect candidates for signals. Form validation status or router's params are great examples here;
• stream of events - those conceptually don't match signals and would not be converted. HttpClient and EventEmitter are perfect examples of APIs that should not be expressed as signals.

In any case we will come back to the API surface review after the initial signals rollout. Any changes will be done in a backward-compatible way and subject to RFCs.

Should I use signals and/or RxJS? What is the difference and role of those primitives?

Signals would be the reactive primitive deeply integrated in the framework and thus a go-to solution for state synchronization needs. This is the first "reactive tool" that people should be reaching out for.

RxJS shines when it comes to orchestrating complex asynchronous operations. Observables power and flexibility comes at a certain cost, mostly related to the learning curve.

We definitively see use-cases where RxJS shines and solves problems in a very elegant way. This is why we are investing in a good interoperability story between signals and RxJS Observables.

Having said this, we would like to see the World where RxJS is adopted by teams as a choice for specific use-cases rather than as a mandated or default "best practice". There are many applications that can be written without complex asynchronous orchestration and we would like to encourage people to experiment with different patterns.

Introducing signals gives us a chance to try different approaches and evolve new best practices.

Why not evolve zone.js instead?

There are a few reasons why we don't think we can achieve our goals by building a better, faster version of zone.js.

The Zone approach isn't scalable.

Zone is based on monkey-patching platform APIs like setTimeout, Promise.then, and addEventListener. This lets Angular know when something has happened in the browser, and we can then schedule change detection to synchronize the UI with any potential model changes.

This approach has not scaled well. zone.js must be loaded before the application starts in order to patch its target APIs. This patching operation is not free, both in terms of bytes downloaded and milliseconds of load time. zone.js also has no idea which APIs the application will use, and must patch them just in case. As browsers add more and more APIs, the cost of this patching grows, as does the cost of maintaining zone.js.

Another major issue is that some platform APIs, such as async / await, are not monkey-patchable at all, requiring awkward workarounds or forced down-leveling.

While we can work to optimize zone.js and reduce these costs, we will never be able to eliminate them completely.

Zones are the root cause of many common pain points in Angular.

In looking back at 7+ years of Angular history and feedback, we've identified zone.js as a common root cause behind many developer experience or performance challenges.

The infamous ExpressionChangedAfterItHasBeenChecked error is often the result of violating Angular's assumptions of how data will flow in your application. Angular assumes that your data will flow from top to bottom along the view hierarchy. This assumption is rooted in how zone.js separates model updates from UI reconciliation, resulting in the potential for "unsafe" model updates.

Another issue we've noted is that zone.js can easily overreact to activity in an application, resulting in many unnecessary change detections. Often this results from third-party advertising, marketing, or analytics scripts being initialized in a way that runs their many timers or other actions in the Angular zone. In the worst cases, we've seen applications which do over 1,000+ change detections at startup. It's always possible to write code with performance problems, but zone.js makes it easy to create such issues unintentionally.

Developers are opting in to more fine-grained reactivity today

Many developers today use state management patterns or libraries that architect their data in a way where they can tell Angular exactly what changed. This usually takes the form of making components OnPush and using Observables together with the async pipe to mark components for check when state they depend on changes. Angular is capable of operating in this mode, but still relies on zone.js for top-down change detection. Thus, developers get some, but not all of the benefits of fine-grained reactivity, and still have to deal with the drawbacks of zone.js.

[jnizet]

Unless I missed something, there are two points that expected to see discussed here and that I didn't find:

1. OnPush is transitive: descendants of OnPush components are effectively OnPush too, because if the change detector doesn't detect input changes on the ancestor OnPush component, then the whole branch of components is not changed-detected. Will this also be the case if a descendant component of an OnPush component is signal-based?
2. What about libraries and ZoneJS? If a library wants to support zone-based applicationand uses, for example, NgZone.runOutsideAngular() to add a DOM event listener and avoid zone-based change detection, then will it be possible to use that library in a zoneless application? Will such libraries have to provide two versions? Or will there be a stub zone where runOutsideAngular() would do nothing?

[nartc]

1. I think it won't be transitive because a child of a Signal-based Component can be either Zone-based or Signal-based.
2. Good question

[JeanMeche]

For 2. they will probably have to rely on using NoopZone on a zoneless app.

[alxhub]

Will this also be the case if a descendant component of an OnPush component is signal-based?

Signal change detection is not transitive - "default" zone-based components inside signal parents still get checked normally, and signal components inside OnPush roots will change detect when their signals fire as well.

Or will there be a stub zone where runOutsideAngular() would do nothing?

Yes, NgZone.runOutsideAngular` will be a noop in a zoneless app.

[yjaaidi]

Actually, it is already there 😉

angular/packages/core/src/zone/ng_zone.ts

Lines 319 to 335 in 5296c04

	export class NoopNgZone implements NgZone {
	readonly hasPendingMicrotasks: boolean = false;
	readonly hasPendingMacrotasks: boolean = false;
	readonly isStable: boolean = true;
	readonly onUnstable: EventEmitter<any> = new EventEmitter();
	readonly onMicrotaskEmpty: EventEmitter<any> = new EventEmitter();
	readonly onStable: EventEmitter<any> = new EventEmitter();
	readonly onError: EventEmitter<any> = new EventEmitter();
	run(fn: () => any): any { return fn(); }
	runGuarded(fn: () => any): any { return fn(); }
	runOutsideAngular(fn: () => any): any { return fn(); }
	runTask<T>(fn: () => any): any { return fn(); }
	}

[EnricoVogt]

No, zone-based change detection will remain supported for the foreseeable future

I don't want to sound negative, but that means at some point in the future we will be forced to migrate our huge applications built on the old model. So should we start the migration early?

What timeframe should we expect under the term foreseeable?

[alxhub]

I don't want to sound negative, but that means at some point in the future we will be forced to migrate our huge applications built on the old model. So should we start the migration early?

At Google there are thousands of Angular applications, some of them very huge, built on zone.js. If the Angular team wanted to drop support for zone.js, we would be responsible for migrating every single one of those applications. I think something major would have to change in the equation for us to even attempt it.

So should we start the migration early?

Well, they're only in developer preview for now, so I wouldn't kick off any projects just yet.

My hope, though, is that signals provide a desirable enough experience that there are real benefits to "migrating". And while we're pretty sure that we can't automate the whole process, we're going to be looking at building tooling for assisted migrations. Many of the items that @e-oz lists, for example, are things that tooling could handle for you. What it can't do is switch over the data flow in your application, since signals behave fundamentally different than zones and require different patterns.

[jelbourn]

"foreseeable" here is meant to communicate that we can't completely predict the future, but that we have no plans whatsoever to end support for zone.js or zone-based change detection and expect them to be around for years to come.

[TheCelavi]

Questions for @alxhub and @jelbourn:

Question 1:

"foreseeable" here is meant to communicate that we can't completely predict the future, but that we have no plans whatsoever to end support for zone.js or zone-based change detection and expect them to be around for years to come.

"Foreseeable future" is the term that describes a long time. However, "long time" is qualitative, opinionated grade which varies from person to person. For someone, long time can be a year, for others 3, 5, 10... and so on. Having that in mind, informing stakeholders of necessary expenditures in terms of developer hours that will incur after "foreseeable future" without any time reference provided will most certainly cause panic. Is Angular team able to better define what "foreseeable future" means? Is it one year, 3, 5? Or maybe "not at least for X years"? Is Angular team able to commit to any, non-vague, time reference?

Question 2:

I think something major would have to change in the equation for us to even attempt it.

Do you have any example of what could be the trigger of such occurrence?

Question 3:

According to Bob Martin, number of developers doubles every 5 years. If that is true (and we have reason to believe it is somewhat accurate, per example, market in my country registered growth of nearly 20% last year), that means that in 5 years, at least 50% of developers will consider Angular component/directive with @Input()/@Output() as obsolete code and task to maintain it as a punishment. Would you agree that even if Angular decides to support current CD model indefinitely, industry (which includes Google) will have to migrate because it will be implicitly forced to, as it will be extremely hard to find devs willing to work on obsolete code (that is, in 5 years it will be consider obsolete)? I am asking about this since this is not unheard of, it was rare occurrence 10-15 years ago, nowadays it is common behaviour.

Thank you.

[elvisbegovic]

@TheCelavi this is smart input, u receive answer anywhere else?

[TheCelavi]

In general, no. I have received same wornout cliché for the answer on Reddit, but nothing useful in general, nothing which can be presented to stakeholders without them asking you "are you mental?", nothing on which future decisions could be based on.

[Harpush]

One question that I am not sure I understood is in the code you showed:

<user-profile [userData]="someRegularVariable" />

You said it will be used as computed but there is no signal here (say zone parent component). How will it work?

What can be done is check whether the provided input is signal based and then use computed or otherwise a new signal. But I am pretty sure that's impossible the same as automatically unwrapping is impossible

[timonkrebs]

if I'll run changeDetectorRef.detach() in the constructor and replace every "| async" to a signal unwrapping, will be changes detected or not? And, what is more important, will it work outside of ngZone?

@e-oz Which case do you mean?

• For the signal to signal case zone.js is not needed. It is not relevant if you are inside or outside of ngZone.
• For zone components it would behave as it does in current versions of angular.

[elgreco247]

In our testing we saw that people were very surprised to loop over an array-of-strings and see each string get "magically" turned into a signal. So instead, we're reading the signal "under the hood" for you, so the for loop behaves more predictably.

@alxhub I think reading the signal "under the hood" is a slippery slope, because when reading the template you have to look at the context of a variable reference to be able to understand whether {{ item }} is a signal or the signal's value. IMHO {{ item() }} should always be a signal value and {{ item }} always the signal itself.

[timonkrebs]

@alxhub I think reading the signal "under the hood" is a slippery slope, because when reading the template you have to look at the context of a variable reference in order to understand whether {{ item }} is a signal or the signal's value. IMHO {{ item() }} should always be a signal value and {{ item }} the signal itself.

I think it is not that bad that people are a little surprised when this is only for the first time you encounter it. If you encounter this you will learn how it works and then have more power to use it however you like. With reading the signal "under the hood" you only take control from the devs. This seems to be related to not so nice edge cases that otherwise would be easy to resolve like: #49684 (comment)

[alxhub]

Control flow is an unexplored topic (mostly), and we probably will have a separate RFC specifically for that in the future.

[Harpush]

@alxhub because control flow is used a lot I think this RFC ought to solve it. Even if nothing new is introduced - at least explain how will it work in frequently used cases (for example #49684 (reply in thread))

[Coly010]

Perhaps I haven't read the overview too well, but I'm seeking some clarification around the following piece:

Input bindings don't automatically trigger local change detection in the receiver
Just because UserProfileCmp receives userData as a computed signal does not mean that any of its views will be change detected when userData changes. Per the golden rule, UserProfileCmp will only be change detected if it reads the userData input signal somewhere in its template.

In other words, inputs which aren't actually used in templates don't trigger any change detection in signal-based components.

When loggedInUser changes, HomePageCmp does not need to change detect any views.
That's because it never actually reads the loggedInUser() value for itself, it only forwards it as a computation to its child component.

Just to ensure my understanding, this following piece will automatically create a computed signal for [userData]

<user-profile [userData]="authService.loggedInUser().data" />

If UserPrfCmp looks something like this (this is just for illustration, I know the authService would have access to stored state):

@Component({
    ...,
    template: `
        <button (click)="logout()">Logout</button>
    `
})
export class UsrPrfCmp {
    @Input() userData: UserData;
    private userService = inject(UserService);

    logout() {
        this.userService.logout(this.userData().id);
    }
}

Because userData is not being read in the template, no change detection will occur if loggedInData is updated. Correct?

Will userData still get the most recent value when the logout method is invoked after the button is clicked?

Essentially, my questions here are:
Can state still be read synchronously with the most recent value from a Signal when it is not used in the template?
Does this mean that state + change detection are now separated more completely?

These questions are how I believe this to be working, but just seeking the clarification around it.

[pkozlowski-opensource]

Because userData is not being read in the template, no change detection will occur if loggedInData is updated. Correct?

Yes, correct.

Will userData still get the most recent value when the logout method is invoked after the button is clicked?

Yes.

Can state still be read synchronously with the most recent value from a Signal when it is not used in the template?

Yes, signals are always guaranteed to return the latest, consistent value.

These questions are how I believe this to be working, but just seeking the clarification around it.

You've got it right!

[Coly010]

Awesome! 🎉 Looking forward to this! Great work!!

[Harpush]

An interesting question here - will the click trigger change detection? I believe it won't? So actually this kind of component has readonly template and will never run change detection after the first time (if at all). Am I correct?

[alxhub]

So actually this kind of component has readonly template and will never run change detection after the first time (if at all). Am I correct?

You are correct.

[mfp22]

Could we rename computed to compute? I like function names as the shortest verb that accurately describes what is happening, and I've always felt a bit weird about computed. It is okay, but why not compute? I think of signal as a verb too, as in, "Hey Angular, please signal this value to the rest of the app." I know there is also precedent for computed though.

[mfp22]

Functions should in general be named verbs, and the use of functions to "do" things in order to construct what you want has nothing to do with imperative vs declarative.

[mfp22]

createSignal, debounceTime, switchMap, concatMap, etc... Even map, reduce. There are many, many examples of functions used in declarative code. My suggestion has a lot of dislikes. Do you not all realize that almost 100% of the functions you use are verbs and computed is an awkward, rare exception?

[mikeandtherest]

@mfp22 I see your point regarding the other methods name, and it's valid. However in this case, a signal represents a noun (and has the Signal, WritableSignal etc. types). Thus, I prefer computed, which is an adjective for the omitted noun "signal" (i.e. computed signal).

Same is the case for effect, which is again a noun. So in this set of new APIs, as far as I can tell, the Angular team did not go with verbs for the naming convention.

[siegenthalerroger]

I have to say I find @timonkrebs ' suggestion a good compromise on the naming side. Using memo(()=> signal() + 1) is very understandable and clear as to the memoisation of the function.

[mfp22]

memo was actually my first choice. https://dev.to/this-is-angular/i-changed-my-mind-angular-needs-a-reactive-primitive-n2g#what-i-want

I like it because it's short, and it parallels SolidJS' naming:
createSignal(0) => signal(0)
createMemo(() => ...) => memo(() => ...)

And I thought this was cool because signal happens to be a verb, so you call it like you're signaling the value, and memo in my head is short for memoize.

computed just makes me feel icky. The only time I've seen it is with Vue.js, which to me is sort of a messy framework. I don't have much experience with it though. It's just my perception from what little I have learned about it.

[timonkrebs]

One thing that probably will get very beneficial is the ability to serialize the reactive graph of signals. This could potentially enable huge benefits when moving into a future where something like react server component (for angular) and/or qwik and/or astro and/or bling would render some things on the server and other things both on server and client.

A serializable reactive primitive would enable really crazy usecases => RSC on steroids.

Is there any consideration about the serializability of the reactive primitive? Or other considerations to be able to get resumability (on client and also even on server)? This will enable a resumability in angular that could even surpass the resumability of qwik.

[alxhub]

In the initial design, we haven't explored serialization of the dependency graph or done any experiments there. Like you, we see the possibilities there as very interesting 😄

[Harpush]

There is a use case we have using a custom made memoize pipe. How would such cases be modeled with signals now?

@Component({
  selector: 'app-test',
  template: `
    Multiplier: {{ multiplier }}
    <button (click)="incMultiplier()">INC</button>
    <div *ngFor="let value of values; let index = index">
      <div>Value: {{ value }}</div>
      <button (click)="incValue(index)">INC</button>
      <div>{{ isEnoughMsg | memoize : value : multiplier }}</div>
    </div>
  `,
})
export class TestComponent {
  multiplier = 8;
  values: number[] = []; // Some real array

  incMultiplier() {
    this.multiplier++;
  }

  incValue(index: number) {
    this.values = [...this.values];
    this.values[index]++;
  }

  // Can be any computation that I don't want to run too many times and can't be created with simple ngIfs in template
  isEnoughMsg(value: number, multiplier: number) {
    if (multiplier < 8) {
      return '...';
    }

    return value * multiplier > 1000 ? '...' : '...';
  }
}

The main "issue" here is the isEnoughMsg. Currently it reevaluates only when the specific ngFor item changes or the global multiplier. with signals that sounds like a computed but it uses a template local variable which isn't available in the component.
Is there some way to create template computed this way? Or maybe this case still holds true even after signals (requiring a pipe)?
In case you can't do it with signals - will it work as expected in signals component?
I can extract this ngFor item template to a different component but seems like a bit of overkill just for having an item signal in TS code.

[pkozlowski-opensource]

@Harpush this is an interesting case, I'm not sure we've got great answer here. Thnx for brining this up, there might be some missing piece here.

[Harpush]

@pkozlowski-opensource Out of curiosity you said:

no, this is not quite accurate - this function would run any time any signal read in a given template / view is notified.

Does that mean each ngIf (template) gets a new effect? So nested ngIfs have nested effects? Or does it work more like an effect with signal based if inside? As I believe if a signal inside ngIf template changes it shouldn't invoke rerender outside the ngIf template. But, if a signal inside the ngIf and the signal controlling the ngIf are changed together the internal ngIf change is actually irrelevant.

[mlc-mlapis]

@Harpush

The pipe is ..., @Pipe({ name: 'memoize' }) ... ... You lose this access if not lambda, of course.

So this is a similar use of a pipe like the pure pipe fn below. Of course, the logic is a bit different.

@Pipe({
    name: 'fn',
    pure: true
})
export class FnPipe implements PipeTransform {

    // A template syntax: {{ templateValue | fn:componentMethodRef:fnArgument }}
    // ... should be transformed to: null.componentMethodRef(templateValue, fnArgument)
    transform(
        templateValue: any,
        fnReference: Function,
        ...fnArguments: Array<any>
    ): any {

        fnArguments.unshift(templateValue);

        // The function reference will NOT BE INVOKED IN THE COMPONENT CONTEXT.
        // This means that the function reference won't have a "this" context
        // during execution, unless the function is pre-bound to the component.
        return(fnReference.apply(null, fnArguments));
    }
}

[elgreco247]

Does that mean each ngIf template gets a new effect?

That's my understanding, because the granularity level is set to be the "view" and ...

Each branch of an NgIf or NgSwitchCase and each row of an NgFor are examples of independent views in Angular.

[alxhub]

Does that mean each ngIf (template) gets a new effect? So nested ngIfs have nested effects? Or does it work more like an effect with signal based if inside? As I believe if a signal inside ngIf template changes it shouldn't invoke rerender outside the ngIf template.

Each view (ngIf template, ngFor row, etc) is independently inside its own "effect" and reacts separately to signals changing.

[gizm0bill]

I seriously don’t understand why don’t you adopt “mobx”? Feels like you are trying to reinvent the wheel here…

[timonkrebs]

How is going with signals anything like reinventing the wheel? Signals are well established and used by much more people than mobx: https://npmtrends.com/mobx-vs-vue not to mention solidjs, preact, qwik etc. In that sense going with signals is the much more reasonable thing to do.

[alxhub]

MobX was one of the inspirations of our design, for sure.

We're building our own signals library, though, because that allows us to very tightly integrate the reactivity system into the core framework, in a way that would've been hard to achieve using the public APIs of an off-the-shelf library.

This is especially important because we need to make our signals work together with zone.js reactivity, which would be exceptionally hard to do without very low level integration points.

[gizm0bill]

yes, this is what I was suggesting, adopt mobx into the innards of the framework

[pkozlowski-opensource]

adopt mobx into the innards of the framework

We did cover our reasoning in the "Why a new library instead of using an existing one?" of #49683

[timonkrebs]

Discussion point 1A: are there other requirements we should consider?

I am not that sure about it any more but when signals where introduced for angular I thought that the solution should be as independent from angular as possible.

I think the approach that ngrx is/was trying to establish to go zoneless with @ngrx/component is really interesting and some parts of this mental model should probably be considered much more when thinking about how to implement fine grained reactivity with signals right now. Fine grained reactivity could be also useful for @ngrx/component and even pure rxjs approaches.

At the moment I am much more on the side that it fits angular to have one opinionated approach for this problem and getting even more opinionated with signals. But I can not get rid of the feeling that we miss some good stuff if we make the approaches of @ngrx/component and part of rx angular obsolete. Or am I missing something here? Will @ngrx/component and similar approaches still be relevant or are signals making all of these approaches completely obsolete?

One thing that I really like about rx angular and to some extent also @ngrx/component is the possibility to have control over the scheduling. I think it would be really great to have the same or even more control over the scheduling with signals.

[alxhub]

We've been working with both the NgRx and RxAngular teams (as well as other key community libraries), and the current design is informed by a lot of their early feedback.

Both of these libraries manually manage change detection, connecting it to their respective paradigms to enable zoneless applications. This is not straightforward - for example RxAngular has workarounds to deal with making sure queries update correctly depending on which views need to be checked.

With signal components, Angular will have a reactive "language" that templates will understand. My hope is that this will be a powerful tool for NgRx, RxAngular, and other such systems, so they won't need to manually manage so much of the change detection process - they can provide even more value with less code / edge case complexity.

Scheduling is a really interesting concept, and something we're actively discussing.

[e-oz]

@timonkrebs
While signals are good for simple things (like updating templates), RxJS is better for events and other asynchronous things (like everything we have on the web page and in XHR). So we can just replace |async with |fromObservable (pipe which is easy to create) and enjoy the best of both worlds ;)

[timonkrebs]

@alxhub Not sure if this really is related, but the discussion seems to go into a different direction anyway. I think my problem is that signals can be useful for things completely disconnected from angular, but the way it now is getting built into angular as a integral part of angular is in my opinion something different.

The part of the integration into angular is the thing that feels not that natural at first. But then this is probably because it is still in a early stage of development.

I think if angular signals would not expose effects and only could be used to trigger updates in the angular template it would feel a lot cleaner and it would be much clearer how to use it. It would be much clearer for what they are useful in angular. It would feel much more guided.

Maybe this is a best practice: not use effects as angular dev. Effects could be something that should only be used by angular and in libraries.

[alxhub]

@timonkrebs I really agree with that - effects are a pretty specialized tool, and are meant to perform rendering actions (creating/destroying components or views, updating DOM, etc) based on the state of the application.

For most other use cases (data fetching, debounce, etc), you want to react to the event that happened (user interaction, etc), not to the state change. Signals work best as the output of event handling (whether it's imperative or functional-reactive style), not as the input to further state changes.

[raedie]

I wonder whether the subject of this RFC is honestly about the introduction of signals. "current proposal" appears to be built on something else entirely rather than just on the basis of adding signals, and I believe the line between what could have been done and what was done has been blurred intentionally.

Ultimately it looks like we are heading towards a new rewrite of Angular and I wonder if it's proper that this results in killing what Angular is today.
It feels disingenuous to propose we could have two parallel angular worlds, one with zone.js and another one entirely different with signals.

There was talk about the ease of adoption, and it seems to me that this is the underlying motivation for introducing these change (alignment to the current framework landscape). I am curious to see how a third rewrite will provide a positive impact on adoption and how many of us might second guess betting the future of a project on angular.

[DmitryEfimenko]

• Not doing this work will stagnate the framework. All issues that we have today will stay.
• Implementing just some parts of the proposal will cause issues with developer experience similar to the issues that we have today with RxJS.

Please move forward with the proposal.

[e-oz]

Nah - right before this RFC, Angular was evolving at an amazing pace. It was not stagnating for sure.

[timonkrebs]

Nah - right before this RFC, Angular was evolving at an amazing pace. It was not stagnating for sure.

This is not true. The Zone.js approach was considered bad long before signals where introduced in angular. Look at what RxAngular and ngrx where pushing and you can see that angular was not in an amazing place. And considering ssr/server components angular was way behind of all other major frameworks. This is a huge leap forward and it looks to me very promising that it can get angular into the lead again.

[e-oz]

Pace, not place. Without any “signals” Angular got non-destructive hydration for the SSR. Right before that, we got inject(), functional guards - it was an amazing pace of development, without breaking changes.

[timonkrebs]

The pace was building up before signals sure. I still do not get why you think this is breaking? As long as nothing gets removed from angular there is nothing breaking.

[gizm0bill]

The logic behind the RxJS "glitch" is fundamentally broken, and it does not highlight the actual "glitch" in any way.
The combineLatest operator, even though the isEven$ depends on the counter$, puts the two actually in the same parallel logic layer, making them independent upon subscription.
What you wanted was to actually use the withLatestFrom operator.
I wonder if this "example" was intentional, or did some RxJS expertise leave this organisation in the meanwhile...

[e-oz]

counter2$ should be ignored - withLatestFrom() will be triggered only by the source observable, not by the observables you pass to withLatestFrom(). That's correct and expected.

[timonkrebs]

@e-oz

You removed the line that was removing the “glitch”, and complaining that now you have a glitch?
Be sure: I’m pretty much aware that signals will be the reactivity primitive in Angular, I’m not trying to change this or convince anyone. But if you want to explain to me how signals are more “flexible” or “powerful” than observables - don’t waste your breath 😎

rxjs is much more powerful than signals when it comes to handling async event streams. But signals are way more powerful when it comes to synchronising state!

My main point is: The problems that signals should solve are not the same as the problems that rxjs should solve.

Your glitch prevention does batch everything that is running in the microtask together. That is not always what we want... But much more important: it is much more verbose and less readable than the "equivalent" done with signals.

const counter$ = new BehaviorSubject(1);


const derived$ = combineLatest([
  counter$.pipe(startWith(undefined)),
  counter$.pipe(startWith(undefined), map(c => c * 2)),
]).pipe(debounce(() => from(Promise.resolve())), map(([counter, counter2]) => counter + counter2));

derived$.subscribe(console.log); // ignored

counter$.next(2); // ignored
counter$.next(3); // ignored
counter$.next(4); //  8 + 4 = 12

vs.

const [count, setCount] = createSignal(1);

const derived = () => count() * 2;

createEffect(() => {
  console.log(derived() + count()); // 2 + 1 = 3
});

setCount(2);  // 4 + 2 = 6
setCount(3);  // 6 + 3 = 9
setCount(4);  // 8 + 4 = 12

[timonkrebs]

@e-oz

counter2$ should be ignored - withLatestFrom() will be triggered only by the source observable, not by the observables you pass to withLatestFrom(). That's correct and expected.

Yes sure in rxjs this is correct and expected (by experienced devs that know rxjs by heart). I do really like rxjs for its consistency when dealing with async streams. But that is not what we always want when syncing ui state. The way signals do this is way more convenient for the tasks that signals should solve.

I really like the explenation of @jelbourn :
#49685 (reply in thread)

[gizm0bill]

I really don’t think you should be comparing signals and observables at all. RxJS forces you into an async nature of code whereas signals do not

[timonkrebs]

I really don’t think you should be comparing signals and observables at all. RxJS forces you into an async nature of code whereas signals do not

That is probably the essence of it. But it is not so easy, because at first glance signals seem to solve someting similar as rxjs. Therefor the question seems to come naturally: What is the difference and can we not solve everything with only rxjs or signals...

Having a good concice answer to that question - one that everyone understands intuitively - seems to be quite important to get people excited for this bright future of angular.

I think we did not come to that point that we can deliver this answer in a way that everyone gets it right from the start - without a deep dive into signals and angular change detection strategies.

I think discussions like that will help with getting closer to a more intuitive explanation for why signals are the best way to solve the change detection issue in angular.

[ctusch]

I really like this RFC. Angular's change detection was one of my major worries when we switched from Ember. Your concept reminds me a lot of knockout.js back in the day.

One question came to mind:
When I migrate a service to signals what will the preferred way be so that it will be usable in signal- and zone.js-based components?

[sunrawat]

@angular-robot Great work team!

@alxhub Great point on migration of large scale apps at google.

To give it an another dimension from an eagle eye view this is what I think why Signal should be introduced at earliest.

We already had OnPush / RxJx strategy to resolve the performance issue (but we use it as per requirement, we are not forced to use it) up to certain levels but
they are tough to understand by many senior developers, developers from other frameworks such as React, Preact, Vuejs as well.

Signal(*) is very much familiar with the React hooks and Computed functions in Vuejs. It will allow not only folks to get an entry Angular world due to more familiarity of concepts but reduces ZoneJs as well as OnPush change detection learning curve for the community.

I have already played around with it and really liked what Angular team has done and achieved :)

[chaosmonster]

I would like to point out that I already found (educational) examples of misused effect functions on the internet.
In the particular example effect() called a method that itself did not include any signals. The reasoning behind this was that the effect function will be called once and was used to initialize the component. Something that would normally be done either in the constructor or a respective life cycle hook.

My point is: This concept brings a lot of confusion and contrary to the standalone component API, it's not simplifying the learning curve of Angular (Zone.js just did its magic in the background and for most applications, especially beginner applications there was no downside to it).

So I would like to bring up the following suggestions.

• leave Zone.js (for an undefined period of time) the default solution in tutorials and code generation, but point out the benefits of signals as an "more advanced" concept.
• throw a warning (in dev mode) if an effect function does not depend on any signals (or computed signals).

[swami-sanapathi]

Even though the set method for signals does not trigger change detection, it is still necessary to use ChangeDetectorRef.markForCheck() to manually trigger change detection.

[pkozlowski-opensource]

Even though the set method for signals does not trigger change detection, it is still necessary to use ChangeDetectorRef.markForCheck() to manually trigger change detection.

No, ChangeDetectorRef.markForCheck() manual calls are absolutely not needed / required with the design described here.

[swami-sanapathi]

I just made an API call and updated the value using the set method in a component that has been configured with the standalone and OnPush options.

Is my understanding correct?

[swami-sanapathi]

Does it require markForCheck?

[pkozlowski-opensource]

@SwamiSanapathi I'm having hard time understanding the scenario that you describing, but having a signal set + having this signal accessed in a template should be enough to mark a component as dirty. You will have to share more details and code example so we can understand more.

[swami-sanapathi]

import { AsyncPipe, JsonPipe, NgFor, NgIf } from '@angular/common';
import { ChangeDetectorRef, Component, OnInit, inject, signal } from '@angular/core';
import { ApiConfigurations } from 'src/app/config/api-config';
import { Article } from 'src/app/models/article';
import { ArticlesService } from './articles.service';
import { ChangeDetectionStrategy } from '@angular/core';

@Component({
    selector: 'app-articles',
    standalone: true,
    imports: [AsyncPipe, NgFor, NgIf, JsonPipe],
    template: `
   
   <div class="space-y-8">
    {{isLoading()}}
    {{articles() | json}}
  <ng-container *ngIf="isLoading(); then loading; else displayArticles">
  </ng-container>
  <ng-template #loading>Loading...</ng-template>

  <ng-template #displayArticles>
    <article class="bg-white shadow rounded p-4" *ngFor="let item of articles()">
      <div class="flex justify-between items-center mb-4">
        <div class="flex space-x-2 items-center">
          <img class="w-10 h-10 rounded-full" src="{{item.author.image}}" alt="Author">
          <div>
            <a href="#" class="text-sm font-bold text-gray-800">{{item?.author?.username}}</a>
            <p class="text-xs text-gray-600">{{item.createdAt}}</p>
          </div>
        </div>
        <button class="bg-green-500 text-white rounded-full h-8 w-8 flex items-center justify-center">
          <span class="material-icons-outlined text-sm">
            favorite_border
          </span>
        </button>
      </div>
      <div class="mb-4">
        <a href="#" class="text-lg font-bold text-gray-800 hover:text-gray-900"
          (click)="globalArticles()">{{item.title}}</a>
        <p class="text-gray-600">{{item.description}}</p>
      </div>
      <a href="#" class="text-green-500 hover:text-green-600">Read more...</a>
    </article>
  </ng-template>
</div>
    `,
    providers: [ArticlesService],
    changeDetection: ChangeDetectionStrategy.OnPush,
})
export default class ArticlesComponent implements OnInit {
    articleService = inject(ArticlesService);
    apiClient = inject(ApiConfigurations);
    articles = signal<Article[]>([]);
    isLoading = signal(true)
    cdRef = inject(ChangeDetectorRef)

    ngOnInit(): void {
        this.globalArticles();
    }

    globalArticles() {
        this.articleService.get(`${this.apiClient.rootUrl}/articles`).subscribe((res: any) => {
            console.log('response -->', res);
            this.articles.set(res.articles);
            this.isLoading.set(false);
            this.cdRef.markForCheck();
        })
    }
}

1. ng-template + signal set + OnPush - needs markForCheck
2. signal set + OnPush - works perfect. @pkozlowski-opensource hope its clear.

[samuelfernandez]

Immutability

To ensure one-directional data flow, using immutability is very important to ensure best practices. Has this been considered for signals? Proposal:

export type Signal<T> = (() => Readonly<T>)&{
  [SIGNAL]: unknown;
};

export interface WritableSignal<T> extends Signal<T> {
  set(value: T): void;

  update(updateFn: (value: Readonly<T>) => T): void;

  mutate(mutatorFn: (value: T) => void): void;

  asReadonly(): Signal<Readonly<T>>;
}

What could be protected:

• Mutation on update, read with signal() and asReadonly()
• Mutation only supported inside mutate

Additionally, as NgRx does, it could provide additional runtime checks for dev mode like freezing:

const names = new Signal([], { freeze: true })

Reference: ngrx/platform#3086

cc brandonroberts

[e-oz]

One of their ideas is: signals allow us to make changes even without following unidirectional data flow (not a quote).

[pkozlowski-opensource]

without following unidirectional data flow

Glad that this is not a quote since this is not what we mean. Signal dependencies form a graph. A directed one. Data change notification flows through this graph in one direction and notify "interested" templates.

This is very much unidirectional data flow. It is just that direction is set by the data dependencies and not visual components hierarchy. This is crucial distinction and essentially the same property we get from modeling state with other reactive graphs (ex. RxJS).

[e-oz]

Glad that you are glad - I had no intent to lie. There is a lot of new information - sorry for the misunderstanding. If needed, I can try to find a video where you are explaining that moment (maybe it’s from ng-bg...).

[samuelfernandez]

@e-oz I was about to cc you, I know you'd be interested. Still impresses me the reply within 10 min, I always find your feedback much interesting 😜

@pkozlowski-opensource my comment was along the lines you mention, directionality should be base on the dep graph, which would be broken by external mutations. As explained, signals primary use case is managing the state, that's why I commented.

Regardless of final decision on this matter, I wonder if the second param of new Signal() should better be an options object in case the API is ever extended instead of the equal fn.

[pkozlowski-opensource]

Regardless of final decision on this matter, I wonder if the second param of new Signal() should better be an options object in case the API is ever extended instead of the equal fn.

It is options object already.