Error NG0601 is reported incorrectly (triggered by NG0600) when calling toSignal inside a computed or effect

[simeyla]

Which @angular/* package(s) are the source of the bug?

core

Is this a regression?

No

Description

Before I begin I want to stress this issue is regarding confusing error reporting and not the signals implementation or design itself. The situation described below is most likely to be encountered when migrating from Observables to Signals, and can lead to confusion.

---

Sample Code

Here is a simple enough computed.

It uses toSignal inside the computed, but let's assume the user is new to Signals and doesn't know they shouldn't do that..

// guaranteed synchronous observables
const store = {
  first$: of('Simon'),
  last$: of('Weaver')
};

// simple computed (inside injection context)
const fullName = computed(() => 
{
    const first = toSignal(store.first$, { requireSync: true });
    const last = toSignal(store.last$, { requireSync: true });

    return first() + ' ' + last();
});

console.log('full name ', fullName());

Output

The above code reports two errors, the first of which is incorrect and misleading.

Error: NG0601: toSignal() called with requireSync but Observable did not emit synchronously.
Error: NG0600: Writing to signals is not allowed in a computed or an effect by default. Use allowSignalWrites in the CreateEffectOptions to enable this inside effects.

It turns out the first error is a side effect of the second error (despite being printed out first). If you only notice the first error (and personally I like to put breakpoints inside the vendor code where they are raised!) then you will be misled.

Explanation

Angular error NG0601 is triggered when an Observable does not emit synchronously when calling toSignal.

  NG0601 `toSignal()` called with `requireSync` but `Observable` did not emit synchronously.

This works internally by subscribing to the observable and checking immediately to see if the corresponding signal has been assigned a value.

angular/packages/core/rxjs-interop/src/to_signal.ts

Lines 179 to 184 in 25153e9

	const sub = source.subscribe({
	next: value => state.set({kind: StateKind.Value, value}),
	error: error => state.set({kind: StateKind.Error, error}),
	// Completion of the Observable is meaningless to the signal. Signals don't have a concept of
	// "complete".
	});

This sets a signal (which begins as StateKind.NoValue) to the synchronous value of the observable, which can then be checked if requireSync == true.

However since ALL writes to signals in computed and effect are forbidden this signal cannot be set, therefore it remains in StateKind.NoValue state, thus triggering the erroneous message:

  NG0601 `toSignal()` called with `requireSync` but `Observable` did not emit synchronously.

Possible Solution

This could easily be solved by introducing a boolean to track the synchronous emission instead of relying on the state of the internal toSignal signal:

  const syncValue = false;   // NEW

  const sub = source.subscribe({
    next: value => { syncValue = true; state.set({kind: StateKind.Value, value}); },
    error: error => { syncValue = true; state.set({kind: StateKind.Error, error}); },
    // Completion of the Observable is meaningless to the signal. Signals don't have a concept of
    // "complete".
  });

  if (ngDevMode && options?.requireSync && !syncValue) {
    throw new RuntimeError(
        RuntimeErrorCode.REQUIRE_SYNC_WITHOUT_SYNC_EMIT,
        '`toSignal()` called with `requireSync` but `Observable` did not emit synchronously.');
  }

[pkozlowski-opensource]

It is really similar to #51055 - in the sense that it creates a new reactive node in a computed. As with #51082 - we could detect it earlier, see a WIP change: pkozlowski-opensource@bce5132

I think that we should take a step back and think about which reactive nodes creation is allowed in which reactive context.

[pkozlowski-opensource]

For now we've got, roughly, those types of reactive nodes and we should try to answer one question: does it make sense to create an instance of a given reactive node while another reactive node is an active consumer. Those are the options - for some of the combinations the answer is pretty straightforward - for others we could debate:

consumer / producer	signal	computed	effect	template effect
signal	na	na	na	na
computed	❌	❌	❌	na
effect	❌	❌	❌	na
template effect	❌	❌	❌	na

✅ - allow
❌ - disallow
na - not applicable (should never happen)

[pkozlowski-opensource]

Minimal reproduction scenario: https://stackblitz.com/edit/stackblitz-starters-w46vxb

[pkozlowski-opensource]

@simeyla #51831 - WDYT?

[simeyla]

Looks great. I do hope people in general won't end up using toSignal() inside a computed though, unless caching it at the same time.

But given that they will, makes me wonder if there should be a companion utility function to get the observable value one time.

If people end up doing toSignal(obs$, { requireSync: true }) () it's pretty ugly.

A utility function, something like syncValue(obs$) wouldn't need to create an intermediate signal and be clearer in intent.

In my 'journey' with nested computed I had to write my own safety checker (expecting #51082 to be imminent) and it actually saved me quite a few times. I found places where I was creating new nodes that wasn't immediately obvious.

I'm guessing you decided not to put this behind a flag (?) but I feel like if there was one it could catch quite a few bugs.

Also, this separate issue can now be marked as fixed: #50106

[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.}