Add "equal" field to ToSignalOptions

[e-oz]

Which @angular/* package(s) are relevant/related to the feature request?

core

Description

Consider adding "equal" field to the ToSignalOptions interface, to let users override the equality check function of the created signal.

Proposed solution

ToSignalOptions with equal

Alternatives considered

Can't find any.

[pkozlowski-opensource]

Consider adding "equal" field to the ToSignalOptions interface, to let users override the equality check function of the created signal.

We could, although I wonder if it is not better handled at the Observable chain level.

[e-oz]

handled at the Observable chain level

At that level, you can control if an observable should emit, but you'll need to create a copy of the produced value if you want to "force" a signal to emit a notification.
In comparison to the requested feature, this option has a higher performance cost, and the code should be either custom for every case, or should have additional checks, like this:

      map((obj) => {
        if (obj == null) {
          return obj;
        }
        if (typeof obj === 'object') {
          if (Array.isArray(obj)) {
            return obj.slice();
          }
          if (obj instanceof Map) {
            return new Map(obj);
          }
          if (obj instanceof Set) {
            return new Set(obj);
          }
          return { ...obj };
        }
        return obj;
      }),

(this code is just an illustration, it's not tested or optimized)

Also, there are some objects that can not be cloned (even using structuredClone()), and they need their prototype chains (so they should not be shallow-copied). For example, DOM nodes.

[alxhub]

I don't think custom equality solves this problem. In particular, custom equality can decide that two referentially unequal values are still "equal" and block the notification, but it cannot decide that a single value has changed if its object identity is the same. That is, equal(x, x) should always be true.

This makes me wonder if we should circumvent custom equality entirely when the value is referentially equivalent...

[e-oz]

but it cannot decide that a single value has changed if its object identity is the same.

Of course it can. Map remains the same object when you modify one of its keys. DOM node remains the same when you modify children. And these are examples of structures that are pretty valid in the role of mutable structures. Immutability has performance costs, and there are cases when you want to say to signal “Yes, it is the same object, but it was updated - I know it for sure”.

if we should circumvent custom equality entirely when the value is referentially equivalent

That would make signals unusable for mutable data structures.

[e-oz]

There is another case (that is most important for me): you want the signal to send a notification every time observable emits a new value, even if this value (accidentally) is the same object.

[alxhub]

That would make signals unusable for mutable data structures.

We removed .mutate for signals precisely for this reason. In particular, when signals and change detection interact, the mutability story falls apart.

Suppose you have a source() signal, and bind it to a sink input:

<sink-cmp [sink]="source()" />

If sink is received as an input signal, then this is effectively behaving during change detection as:

sink.set(source())`

The problem is that mutability gets lost here - change detection will only set sink if source() changes its referential identity, regardless of how often the source signal notifies of changes. Effectively, mutable change notifications are lost at this boundary.

[e-oz]

But signals are not only for change detection. There might be layers and layers of computed signals before the result is consumed by the change detection logic.

I’ll quote my tweet:

This strategy would make sense if Angular Signals were a Change Detection Reactivity Primitive, not a General Reactivity Primitive.

At this moment, I even think that Angular Signals would evolve better outside of Angular repo - as a separate library, like RxJS, and it would make them framework-agnostic, and they would evolve as a General Reactivity Primitive.

If you convert signals into a Change Detection Reactivity Primitive, they will only be used as the “async” pipe - users will convert observables into signals only at the last step when they go to the template.

Maybe it's exactly what you want, I don't know.

[e-oz]

This request has no sense after #52465 ;)

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}