[Complete] Sub-RFC 4: Observable and Signal Interoperability

[dylhunn]

Sub-RFC 4: Observable and Signal Interoperability

Changelog

April 10, 2023

• fromSignal and fromObservable renamed to toObservable and toSignal, respectively.
• By default, the type of toSignal will be Signal<T|undefined> where T is the return type of the Observable.
• Added section detailing the obstacles to implementing InteropObservable.

Introduction

Many existing applications and libraries use RxJS to manage state. Observables should be able to interoperate with these applications. To solve this problem, we propose two new APIs: toSignal and toObservable, both exported from the @angular/core/rxjs-interop package. The goal with these functions is to provide a lightweight and sensible default bridge between Observable and Signal concepts. This allows interop with existing RxJS code and optionally enables every Signal-based API in Angular to be used with RxJS, for much more complete support (for example, unlocks inputs as observables).

RxJS is a powerful and feature-rich library and there will certainly be cases that are not covered in these default behaviors. Rather than trying to include every possible feature, we want to make sure what we're including covers most use-cases without bloating the API in order to support uncommon scenarios.

toSignal

You can convert an Observable to an Angular Signal by using the toSignal function.

export function toSignal<T, U extends T|null|undefined>(
    source: Observable<T>, options: {initialValue: U, requireSync?: false}): Signal<T|U>;
export function toSignal<T>(
    source: Observable<T>, options: {requireSync: true}): Signal<T>;

The two different signatures support two different ways of dealing with the initial value (see the "Asynchronicity" section below).

const counter: Signal<number> = toSignal(counter$);

Managing the subscription

The toSignal function internally subscribes to the given Observable and updates the returned Signal any time the Observable emits a value.

This subscription will be created immediately as opposed to waiting until the Signal is read. We do this intentionally because we do not want the signal read to have side effects (e.g. opening a network connection on subscription). If the subscription were created lazily, then the act of reading the signal for the first time would have the side-effect of creating the Observable subscription and this may have its own side effects. This is also how the async pipe works.

Angular will automatically unsubscribe from the Observable when the context in which it was created is destroyed. For example, if toSignal is called in a component or directive, then the subscription is cleaned up when the component or directive is destroyed. If it is instead created in a service, it will be cleaned up when that service's injector is destroyed.

Asynchronicity

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. Signals, on the other hand, are always synchronous. The signature of the toSignal function supports both synchronous and asynchronous Observables.

Initial Values

Before the Observable emits, the signal returned by toSignal must have an "initial" value.

If not provided explicitly, this initial value is undefined (similarly to how the async pipe returns null initially).

const data: Signal<string|undefined> = toSignal(http.get('/data'));
console.log(data()); // "undefined" before the data is available

There are many cases where undefined is not the best choice of initial value. For these cases, toSignal allows the initial value to be configured directly:

// The first value will not be emitted until 5 seconds later
const secondsObs = interval(5000);
// Provide an initial value of zero.
const seconds = toSignal(secondsObs, {initialValue: 0});
effect(() => {
  console.log(seconds());
});

Requiring synchronous emit

Some Observables are known to emit synchronously. In those cases, you can have toSignal verify that the Observable produces a value immediately, and forgo providing or dealing with an initial value.

// BehaviorSubjects emit synchronously:
const balance$ = new BehaviorSubject(50);

const balance: Signal<number> = toSignal(balance$, {requireSync: true});

This is a trade-off: requiring a synchronous emit avoids any need for handling of undefined values (or manually configuring initial values). However, if balance$ is ever made asynchronous (such as by adding a debounce operation, for example), toSignal will throw an error.

Error and completion states

A signal is a wrapper around a value, which is capable of notifying interested consumers when that value changes. An Observable has three types of notifications when an Observer subscribes to it: next, error, and complete.

A signal's value is directly linked to the values coming from the next notification of the Observable.

When the Observer created by toSignal is notified of an error, it will throw this error the next time the signal is read. This error can be handled the same way any other error coming from a signal would be:

const mySignal = toSignal(myObservable$);
try {
  mySignal();
} catch (e: unknown) {
  // Handle the error from the observable here
}

If handling the error where the signal is used is not desirable, the error can be transformed either on the Observable side (via catchError) or on the signal side (via computed):

const mySignal = toSignal(myObservable$.pipe(catchError(() => of('error')));

const mySignal = toSignal(myObservable$);
const mySignalNoErrors = computed(() => {
  try {
    return mySignal();
  } catch {
    return 'error';
  }
);

Signals do not have a concept of being "complete," because they are just wrappers around a value. When an Observable is complete, the Observer created by toSignal will simply not receive new values from the stream. We acknowledge that the completion state does have a meaning for an Observable and sometimes you might care about this. Even with it not being surfaced directly in the returned signal, this state can be represented in a different signal, for example:

const isComplete = signal(false);
const signalFromObservable = toSignal(
  myObservable$.pipe(finalize(() => isComplete.set(true)));
);

There’s also a materialize operator that “represents all of the notifications from the source Observable as next emissions marked with their original types within Notification objects.” This pipe could be used to surface both the complete and error notifications.

toObservable

toObservable is a function that takes an Angular Signal and returns an Observable. It does this by creating an effect when the Observable is subscribed to, which takes values from the signal and streams them to subscribers.

const count: Observable<number> = toObservable(counterObs);

Lifecycle and Cleanup

Observables are designed to manage the lifecycle of the side effects they create. When a toObservable Observable is subscribed, it creates an effect to monitor the signal, which exists until that subscriber unsubscribes.

This differs from toSignal, which automatically cleans up its subscription when the component or service which invoked it is destroyed.

We believe it would be incorrect for toObservable to tie the resulting Observable to the lifecycle of the enclosing component, for two reasons:

1. The incoming Signal might itself not have the same lifecycle as the component. Signals are valid as long as anyone still has a reference, and the signal may have been passed in externally.
2. The Observable might be used in other external RxJS computations, such as being passed into a switchMap. Moreover, it could be passed into a service and persisted. Finally, observable unsubscriptions might have side-effects, and the user should control when those run, as with other Observables.

If desired, it's straightforward to tie the resulting Observable to the component's lifecycle manually:

const myValue$ = toObservable(myValue).pipe(takeUntil(this.destroy$));

All values are asynchronous

The Observable produced by toObservable uses an effect to send the next value. However, because effects are by nature asynchronous, the Observable emissions will be asynchronous, even for the first value.

Therefore, all values emitted by the toObservable Observable are delivered asynchronously.

This has some interesting consequences. Consider setting a signal several times in a row, which is a synchronous operation:

const obs = toObservable(mySignal);
mySignal.set(1);
mySignal.set(2);
mySignal.set(3);

The observable obs will only ever produce the value 3, because the signal is set synchronously, but the observable is scheduled to update asynchronously. In this way, a Signal is subtly different from a BehaviorSubject. In other words, unlike Observables, signals are not streams.

We do not emit the first value synchronously. To do so, we'd have to skip the first emission in the effect -- but what if the signal updates before the effect is scheduled for the first time? We'd need to check the signal's value equality, which might not be reliable (e.g. a mutated object).

If you want to get the first value synchronously, you can straightforwardly implement this behavior as so:

const obs$ = toObservable(mySignal).pipe(startWith(mySignal()));

One Effect for All Observers (via shareReplay)

If you expect to have many subscribers to an observable produced from a signal, you might want to use the shareReplay operator. This helps you avoid creating a new effect for each subscriber.

This would look something like the following:

const obs = toObservable(mySignal).pipe(
  shareReplay({refCount: true, bufferSize: 1})
);

refCount is set so that the underlying effect is cleaned up after all users unsubscribe. The bufferSize is one because we only care about caching the latest value.

Why not do this automatically inside toObservable? There are a few potential reasons:

• Inconsistent behavior: The first subscriber will receive its value asynchronously, but later subscribers will be synchronously replayed.
• Code size: We'd have to include shareReplay for everyone using RxJS interop, when some applications may not want it.
• Easy to implement: As shown above, it's easy to use shareReplay yourself if you want this behavior. It's not nearly as easy to get rid of it, if you care about the sync/async discrepancy.
• Low overhead: Registering multiple effects incurs minimal performance cost, comparable to a subscription to a shareReplay observable.

InteropObservable

An idea that came up during the discussion was to make signals implement InteropObservable. While this can work in some situations, we ultimately decided against it for two principle reasons:

1. Watching a signal requires an injection context.

This is because effects fundamentally need access to the effect scheduler for the application they're running in, so we'd need to use inject to get ahold of it.

This would be a very surprising and burdensome requirement for anyone trying to put signal reads inside e.g. switchMap, since Observable pipelines don't typically run with injection contexts. You'd have to wrap the operators in runInInjectionContext, which would be painful and boilerplate-y. An explicit conversion from signal to observable outside of the observable pipeline is actually more ergonomic.

For example, the following pattern:

something$.pipe(
  switchMap(v => dataSignal),
)

may function correctly if the initial emit is synchronous, but error later on when the switchMap operator tries to call the InteropObservable API on dataSignal internally the next time something$ emits, because it'll no longer be in an injection context.

Additionally, there is no straightforward way to fix this issue, because the injection context comes from the event source (whatever produced the next value to something$), not the Observable chain creation. So it's not possible to wrap switchMap in runInInjectionContext - a custom, injection-context-aware operator would have to be used instead.

Overall, this adds a level of friction that we felt undermines any potential convenience of InteropObservable.

2. Signals are not Observables and converting between them should be an intentional operation.

This part of the argument is more philosophical. Just like how subscribing to an Observable has side effects and manual subscriptions should be done with care, choosing to use the signal graph to manually drive additional data flow should also be done with consideration for the impact on the application's architecture. In some cases it can be necessary, but often there are better patterns such as driving Observable chains from the original application events, rather than as side effects of signal updates.

takeUntilDestroyed

Angular users often want to complete a stream when a related subject completes. The following illustrative pattern is quite common:

destroyed$ = new ReplaySubject<void>(1);

data$ = http.get('...').pipe(takeUntil(this.destroyed$));

ngOnDestroy() {
  this.destroyed$.next();
}

We are introducing a new RxJS operator called takeUntilDestroyed, which simplifies this example into the following:

data$ = http.get('...').pipe(takeUntilDestroyed());

By default, this operator will inject the current cleanup context. For example, used in a component, it will use the component's lifetime.

takeUntilDestroyed is especially useful when you want to tie the lifecycle of your toObservable Observable to a particular component's lifecycle.

However, if you want to override the default behavior, you can manually provide a DestroyRef. This lets you call takeUntilDestroyed outside of a context where inject is available.

[e-oz]

Thank you for this RFC, I see that your team made practical research, not only theoretical :)

Discussion point 4a (Initial value)

Runtime errors are the worst. It is better to prevent an error at the compilation stage (one of the reasons why I love Rust so much).

Please consider creating different functions (or overload fromObservable() using params) to let the user explicitly select desired behavior and consequences. This way you will not need to guess what the user expects, and the user will not be surprised by runtime errors.

For example:

// initialValue is not optional
function fromAsyncObservable<T = unknown>(obs: Observable<T>, initialValue: T): Signal<T>; 

// throw an exception on creation if an observable is not actually async (would be great if we could catch it at the "build" stage)
function fromSyncObservable<T = unknown>(obs: Observable<T>): Signal<T>; 

// if we have no information, we should assume that the given observable can be async
function fromObservable<T = unknown>(obs: Observable<T>, initialValue: T): Signal<T>; 

Managing the subscription

For: fromObservable()

Angular will automatically unsubscribe from the Observable when the context in which it was created is destroyed. For example, if fromObservable is called in a component or directive

I guess it's planned to be implemented (or already implemented) using DestroyRef, so described behavior will only work when fromObservable() is called in the "injection context". It's opaque to the user and not obvious - I prefer the explicit approach you are using with fromSignal() (especially when it's so easy to add takeUntilDestroyed()).

shareReplay

What kind of Observable fromSignal() will return - "hot" or "cold"? If it's hot, then we don't need shareReplay() (agree with your "low overhead" argument), if it's cold - that's weird. Signals are "hot", so it is expected to get hot observables after the conversion. It would be much handier to operate hot observables, received from signals (behavior would be more predictable).

---

I'm thankful for having a chance to participate in this discussion! Good luck with this challenging task :)

[JeanMeche]

+1 on a non-throwing overload (or other function) :

I would have seen more something like :

function fromObservable<T = unknown>(obs: Observable<T>, initialValue: T): Signal<T>;
function fromObservable<T = unknown>(obs: Observable<T>, initialValue = null ): Signal<T|null>;

With a nullable value by default, be could also be anything else.

[atscott]

I guess it's planned to be implemented (or already implemented) using DestroyRef, so described behavior will only work when fromObservable() is called in the "injection context". It's opaque to the user and not obvious - I prefer the explicit approach you are using with fromSignal() (especially when it's so easy to add takeUntilDestroyed()).

It has to be run in an injection context (or given an injector) because the inner effect has to be registered with the ApplicationRef. Effects are flushed during change detection (06e74a5). fromSignal doesn't have anything that has to be scheduled or cleaned up so it's quite different in that respect.

[e-oz]

Yeah, that's where all of these hidden dependencies will start biting. In a hard way, developers will learn that fromObservable depends not only on DestroyRef, but also onApplicationRef.

[bryanerayner]

4a - I think you should use function arity and detect if fromObservable is called with a default value - so undefined would not be a default value unless explicitly called.

Alternatively you could use a fluent interface to allow a default option to be specified.

I feel like throwing errors by default only leads to pain and I know our team will always be using anything that avoids errors being thrown. If we had to pick between 2 and 3, we'd pick three.

[jgbpercy]

4A seems like a real puzzler... Gut feel is that the standard we'll adopt in practice is, 99.9% of the time:

• Pass a possibly async Observable with an initial value OR
• Pass some known sync Observable (BehaviorSubject or a ReplaySubject we know has seen a value) to a userland-implemented wrapper util that implements behavior 1 (subscribe synchronously and error if no sync value). I'd personally prefer if a blessed version of that util was part of the interop package (as proposed by @e-oz in another comment) but also appreciate the desire to keep the API surface lean.

Given the above, maybe my opinion here is moot, but option 2 for the default behavior of fromObservable does feel shaky... I can imagine scenarios where in thorough testing you never hit the specific conditions where the Observable hasn't emitted before Signal read, and then this happens to 1% of users in prod. But maybe this isn't much of an issue in practice...

[robert-king]

i'm thinking you should just make fromObservable() require a defaultValue. it's the simplest. Maybe if you have a synch observable you can use it without a required defaultValue, as long as that can be a compile time error. you can always go fromObservable(obs$, undefined) to provide undefined as the default value. Although I think some people might use Subject() for triggers where they go trigger.next(undefined) and trigger.asObservable(). not sure.

[alxhub]

Maybe if you have a synch observable you can use it without a required defaultValue, as long as that can be a compile time error.

That's part of the problem - it can't be a compile time error, because there is no way of knowing at compile time if any particular Observable is synchronous or not.

[bryanrideshark]

I think always requiring a default value is the best way to go - And then if it's not provided, assume the type is always "X | undefined". If teams have a problem with that, I don't know what to tell them, you've written code which is potentially undefined, why are you mad at the compiler for telling you the truth?

[alxhub]

@bryanrideshark we ended up adopting very nearly that same design - initial value is undefined unless an explicit value is provided.

We do have a flag requireSync which will make toSignal throw if the Observable doesn't emit synchronously. This allows you to opt-in to a more ergonomic type if you know the Observable always emits, which comes with the risk of a runtime error if that assumption is later invalidated. Now, though, this runtime error happens from toSignal itself, not when you read the signal, so there's no risk of subtle breakages only in certain cases.

[benlesh]

First off, I found some potentially buggy code in your fromSignal implementation, you might want to checkout (See the IMPORTANT comment in the first example)

And I have a couple of suggestions:

1. As you probably know implementing Symbol.observable on your Signal will make the signals "just work" with RxJS.

2. In RxJS version 8, simply having a subscribe method (being "subscribable") will also mean that the Signal will work 100% with all RxJS APIs.

In either case, I think Symbol.observable offers the least intrusive API.

if (typeof Symbol.observable === 'symbol') {
    signal[Symbol.observable] = () => ({
        subscribe(observer) {
            let active = true
            const watcher = effect(() => {
              let value;
              try {
                // IMPORTANT: When dealing with any reactive function call you don't control
                // like `observer.next()` (or anything similar), you want to catch the error 
                // in the producer call, in this case `signal()`. You don't want to catch errors
                // in the `observer.next` call itself. (this is a common mistake and it's not
                // unique to RxJS, you'll see it in the next example as well)
                value = signal()
              } catch (err) {
                observer.error(err);
                return;
              }
              observer.next(value);
            }, {injector, manualCleanup: true});
            return {
                unsubscribe() {
                    if (active) {
                        active = false
                        watcher.destroy()
                    }
                }
            }
        }
    })
}

However... option 3 may be more platable, which is to implement Symbol.asyncIterator, which also converts directly to Observable (albeit less directly). But has EVEN MORE INTEROP with "The Platform" and also converts directly to RxJS observables with no extra effort (as well as allowing users to "subscribe" to changes to signals using for-await loops:

signal[Symbol.asyncIterator] = () => {
  const deferreds = []
  let dirty = true

  const handleError = (reason) => {
     // Called during errors
    while (deferreds.length) {
        deferreds.shift()!.reject(reason)
    }
  }
  
  const watcher = effect(() => {
    let value;
    try {
        value = signal();
        dirty = true
    } catch (err) {
        handleError(err)
        return
    }

    if (deferreds.length) {
        dirty = false
        deferreds.shift()!.resolve({ done: false, value })
    }
  }, {injector, manualCleanup: true});

  return {
    next() {
        return new Promise((resolve, reject) => {
            if (dirty) {
                dirty = false;
                resolve({ done: false, value: signal() })
            } else {
                deferreds.push({ resolve, reject })
            }
        })
    },
    throw(reason) {
        handleError(reason)
        watcher.destroy();
    },
    return() {
        // Called as a finalizer.
        while (deferreds.length) {
            deferreds.shift()!.resolve({ done: true, value: undefined })
        }
        watcher.destroy();
        return Promise.resolve({ done: true, value: undefined })
    }
  }
}

And then your signal can be consumed in the following ways:

import { from, of, concatMap } from 'rxjs':

// These two work with Symbol.observable or Symbol.asyncIterator
const source$ = from(signal);
const source2$ = of('test').pipe(concatMap(() => signal))

// This one only works with Symbol.asyncIterator
async function test() {
  for await (const value of signal) {
    console.log(value)
    if (value === 3) {
      // it'll even stop watching here.
      break;
    }
  }
}

Why should you consider a better interop change than fromObservable?

• fromObservable is a bad name. haha... Sorry, fromX idiomatically is going to mean "I'm creating an observable" to a lot of folks (and that's probably my fault, but whatever)
• If Angular's signal works with from, it'll be incredibly easy for people to use signals with Observable operators they're already familiar with.

const observableToSignal = fromObservable; // fromObservable is a bad name

import { r, concatMap, map, filter } from 'rxjs';

const newSignal: Signal = r(
  signal, // <-- A signal!
  concatMap(fn), // <-- familiar RxJS operators!
  map(fn2),
  filter(fn3),
  observableToSignal // <-- back to a signal!
)

Final suggestion:

Maybe spend more time talking to your old friend, Ben. The RxJS team hasn't heard from y'all in years. I still love you, despite leaving in 2019. :)

[alxhub]

To circle back on this: currently our thinking that Signal should not implement InteropObservable or any Subscribable interface is unchanged. Largely this comes down to two main arguments:

1. Watching a signal requires an injection context.

This is because effects fundamentally need access to the effect scheduler for the application they're running in, so we'd need to use inject to get ahold of it.

This would be a very surprising and burdensome requirement for anyone trying to put signal reads inside e.g. switchMap, since Observable pipelines don't typically run with injection contexts. You'd have to wrap the operators in runInInjectionContext, which would be painful and boilerplate-y. An explicit conversion from signal to observable outside of the observable pipeline is actually more ergonomic.

2. Signals are not Observables and converting between them should be an intentional operation.

This part of the argument is more philosophical. Just like how subscribing to an Observable has side effects and manual subscriptions should be done with care, choosing to use the signal graph to manually drive additional data flow should also be done with consideration for the impact on the application's architecture. In some cases it can be necessary, but often there are better patterns such as driving Observable chains from the original application events, rather than as side effects of signal updates.

[e-oz]

Signals are not Observables and converting between them should be an intentional operation.

This part of the argument is more philosophical

Then revert all of these philosophical “signals” things and use observables as a reactive primitive.

[benlesh]

1. Watching a signal requires an injection context.

Again, I can't reiterate this enough: You have the control to do this.

// in psuedo-code
new Observable(subscriber => {
  waitForInjectionContext().then((context) => {
    // do whatever.
    subscriber.next(signalHere())
  })
})

2. Signals are not Observables and converting between them should be an intentional operation.

One of the stated goals of this implementation is

Significantly improved interoperability with reactive libraries such as RxJS.

I'm popping in here to say it's a near miss. The easier interop is the better. It seems like there's an effort to make it difficult. I don't think anyone is going to unintentionally return a signal from concatMap.

Presumably, Angular will want to lean more heavily on signals for more of it's APIs. The Angular ecosystem has evolved to run almost entirely off of RxJS observables (I'm not even saying that I think that's a good thing, it just is what it is). IMO, some of this was because of the long churn on Ivy, the embattled Zones proposal, and a push (at least back in 2017-2018) towards solutions like ngrx, et al, in the absence of new development because of the time spent on Ivy.

I think signals would be a great thing to use for <input/> changes, for example... however, people are going to want to wire these things up to switchMaps and debounceTimes et al, so they can kick off http.get()s in reactive ways. I don't see a reason to make this require any more boilerplate or typing than is necessary.

Unrelated, I'd love to work with y'all on guidelines for when observables should be used and when signals should be used. I've already been having this discussion with curious folks regularly. I don't have any agenda to make sure observables are used. I don't get paid by the observable. In fact, I don't get paid at all.

[kedevked]

I totally do agree that interop should be a key point of the design. I have seen the updated changelog. But I still strongly believe that signals should work with the from operator of rxjs

[PowerKiKi]

@benlesh can you confirm that the private discussion you suggested actually took place (without revealing any of its content) ? Or is it something that the Angular team did not have time to address yet ?

[yjaaidi]

I thought we already discussed adding alternative names to fromObservable() and fromSignal() as a discussion point in this RFC, but I can't find it.

A typical example is myFunction(toSignal(source$)) which gives more information than myFunction(fromObservable(source$)).

[AhsanAyaz]

toSignal and toObservable sound great!
@alxhub would signals always be a part of @angular/core? Or maybe @angular/core/signals? As toObservable coming out of @angular/core seems less intuitive to what we’re really converting to an observable.

[alxhub]

@AhsanAyaz they're exported from @angular/core/rxjs-interop.

[HCenggel]

I love toSignal too !

mo too

[e-oz]

would be nice to have toPromise() also.

[DmitryEfimenko]

I strongly support naming toSignal and toObservable rather than their from counterparts.

[Lonli-Lokli]

From my point of view if we must have runtime error they should happen as early as possible

[benlesh]

My two cents on 4a:

I'd say probably throw an error as soon as possible. On read is fine. Otherwise it could get weird when people use this compositionally. Once types are corrected on RxJS 8, this will work (and it technically works now, just TypeScript will complain):

const tickerSignal = timer(0, 1000).pipe(
  startWith(0),
  toSignal
)

Alternatively, you just make the default value mandatory. Then I'd recommend providing an operator at some point (or people can just roll their own):

const asSignal = (defaultValue: T) => (source: Observable<T>) => toSignal(source, defaultValue);

const signal = someObservable$.pipe(
  asSignal('default value')
)

[vijhhh2]

Interoperability using rxjs operators like @benlesh explained is the way it should be. fromObservable or fromSignal somehow I feel it's not like angularish, more precisely rxjs way.

[HyperLife1119]

Is this supported? It converts input directly into observable.

class MyCmp {
  count$ = fromSignal(input(1))
}

[alxhub]

No, this won't be supported. The only form of input() usage the compiler will accept is:

class MyCmp {
  // optionally: protected and/or readonly
  count = input(1);
}

That is, it must be assigned to a field.

[eneajaho]

No, this won't be supported. The only form of input() usage the compiler will accept is:

class MyCmp {
  // optionally: protected and/or readonly
  count = input(1);
}

That is, it must be assigned to a field.

Can we have:

import { input as routeInput } from "@angular/core";

class Cmp {
  userId = routeInput<string>();
}

When using withComponentInputBinding for the router.

So basically just an import rename.

The compiler should be able to support a case like this I think.

[benlesh]

No, this won't be supported.

Curious as to why here, @alxhub?

You control the observable implementation returned by fromSignal. It can hold any reference and defer for as long as is necessary. If it's due to compiler magic not being easy, I'd say just wrap it in a function fromSignal(() => someSignal()), where the () => someSignal() is only called when the framework is able to call it. Asynchrony is on your side here.

[benlesh]

Alternatively, just pass the signal itself without calling it, and let your observable implementation resolve it whenever the framework is ready: fromSignal(someSignal). I don't see a reason why this couldn't be done at any time, just so long as you had the reference.

[alxhub]

Curious as to why here, @alxhub?

Well, all things are possible with code, of course (and maybe a sufficiently advanced compiler). Thinking through what would be required though:

• The runtime needs a reference to the actual input signal (not just the Observable) in order to set values
• The compiler needs to know which inputs exist.
• The template type-checker needs to be able to type-check a binding to each input.

Making all 3 of these aspects work properly would require a lot of special casing:

• toObservable would have to recognize that it's being called with the special input signal.
• toObservable would have to return, in that case, a special Observable instance with the input signal patched onto it.
• When setting the input value, the runtime would need to identify this special Observable and extract the real input signal.
• The compiler would need to recognize the toObservable(input()) pattern specifically as a valid way to declare an input.
• Any generate .d.ts files would need to carry through the information that this input is specially typed.
• The template type-checker would need to understand that this input is specially typed.
• The template type-checker would need a transform to extract the type of the input signal from the type of the Observable field, in order to type-check against it.
• The documentation would need to explain that toObservable(input()) is an exception to the rule that input() and other special Angular declaration functions are not composable.

All of this complexity would be an extra dimension on top of the challenges of interoperability between signal and zone components, which require similar considerations at all layers of the stack. Given the ease and simplicity of declaring the input() and then separately calling toObservable(), it doesn't make sense to take on the extra complexity and the tight coupling with framework internals that supporting this pattern of a wrapped input() would involve.

[menosprezzi]

Maybe the mental model behind the signals can implement the InteropObservable type to build the bridge between rxjs and signals, translating between both will ease!

Implementing InteropObservable interface you can use the signal directly in your rxjs pipes if you need.

For instance, lets say that angular changes the @input to wrap values into a signal, you can still use it with the rxjs's reactive utils if you need and the code will look cleaner:

class MyCmp {
  @Input()
  value: Signal<number>;

  ngOnInit() {
    const aNativeObservable$ = this.myService.get();
    combineLatest([this.value, aNativeObservable$]).pipe(/* and so on :D */ ) 
  }
}

Also, no need to worry about signals implementation depending directly on Rxjs. The implementation doesn't need even to import it! All it has to do is to provide a subscribe method.

[kbrilla]

if requireSync is provided then no | undefined is required in the return type right?

[elgreco247]

Right: https://github.com/angular/angular/pull/49769/files#diff-90f149f8132bdfb5ad304aca758b2006175bd63d041475e17e98a705732351a2R36

[swami-sanapathi]

Could someone figure out the issue, seems the issue is clear here. or did i miss anything?

version: 16.0.0-rc.0
error: ./node_modules/@angular/core/fesm2022/rxjs-interop.mjs:10:0-56 - Error: Module not found: Error: Package path ./src/errors is not exported from package

    import { signal } from '@angular/core';
    import { toObservable } from '@angular/core/rxjs-interop';


    count = signal<number>(1);
    obs$: Observable<number> = toObservable(this.count);

[JeanMeche]

Ok I got it on rc0, update to rc1 to fix it !

[swami-sanapathi]

yes its fixed. :D Thank you @JeanMeche

[swami-sanapathi]

Ouput

N0100: ExpressionChangedAfterItHasBeenCheckedError: This error just won't leave us alone! 😂

[JeanMeche]

Seems like @atscott has a fix for you :)
#49894

[swami-sanapathi]

Yayy 😍😍 thank you @atscott

[spierala]

Would it be possible to provide a isSignal function, to detect reliably if a given object is a Signal?

Similar to RxJS isObservable: https://rxjs.dev/api/index/function/isObservable

Or is there another good way to detect Signals?

[elgreco247]

It's already there: https://github.com/angular/angular/blob/main/packages/core/src/signals/src/api.ts#L35
And is exported: https://github.com/angular/angular/blob/main/packages/core/src/signals/index.ts#L9

[timonkrebs]

I could not say it better than @e-oz:

Thank you for this RFC, I see that your team made practical research, not only theoretical :)

But there is one thing with signals in angular that feels not right to me. And it has also implications for the Observable and Signal Interoperability. It is the scheduling of effects:

The Observable produced by toObservable uses an effect to send the next value. However, because effects are by nature asynchronous, the Observable emissions will be asynchronous, even for the first value.

Therefore, all values emitted by the toObservable Observable are delivered asynchronously.

This has some interesting consequences. Consider setting a signal several times in a row, which is a synchronous operation:

const obs = toObservable(mySignal);
mySignal.set(1);
mySignal.set(2);
mySignal.set(3);

The observable obs will only ever produce the value 3, because the signal is set synchronously, but the observable is scheduled to update asynchronously. In this way, a Signal is subtly different from a BehaviorSubject. In other words, unlike Observables, signals are not streams.

I think it is a reasonable default, th have obs only produce the value 3. But sometimes it would be essential to get triggered for all the values.

It would be really nice to be able to configure the scheduler for the effect in toObservable. Something like:

 * Options passed to the `effect` function.
 *
 * @developerPreview
 */
export declare interface ToObservableOptions {
    /**
    *
     synchronousScheduler | trigger effect immediatley
     queueScheduler | Schedules on a queue in the current event frame (trampoline scheduler). Use this for iteration operations.
     asapScheduler | Schedules on the micro task queue, which is the same queue used for promises. Basically after the current job, but before the next job. Use this for asynchronous conversions.
     asyncScheduler | Schedules work with setInterval. Use this for time-based operations.
     animationFrameScheduler | Schedules task that will happen just before next browser content repaint. Can be used to create smooth browser animations.
    *
    */
   scheduler?: SCHEDULER
}

This could be used like:

toObservable(mySignal, { scheduler: synchronousScheduler  });

[DibyodyutiMondal]

It'd be great to have this.

My 2 cents, though:

Given that, streams != signals, the situation described above is a direct consequence of 'signal -> obs' conversion, and only occurs when we do that conversion.

But, in practice with the v16 rc so far, whenever I have had to work with observables, they always happen be a 'source' and I only perform 'obs -> signal' conversion at some point.

1. Whenever I've needed to work with a stream (i.e, every single emit is important), I have found that I can simply do the conversion to signal after I have piped the observable stream to do whatever it is I need to do
2. if I don't care about every single emit, I'll convert the obs to a signal and then use an effect/computed signal as appropriate for further computation.

As a result, I have not used 'signal -> obs' conversion in practice at all. Of course, this is probably project specific (or developer specific?), so, I am curious to see a situation where 'signal -> obs' is required, just so I can widen my horizon a bit.

[timonkrebs]

I think you are right. It would not be needed that much.

But if you would consider using effect in user code an anti pattern this could get relevant. I do not have any specific usecase in mind at the moment. But then that might be because I think of Angular from a rxjs perspective as well as you seem to think about it. If people start using angular with signals this mindset will probably change...

If you start from signals only and then get into more complicated use cases where you need rxjs this will change the picture...

[DibyodyutiMondal]

if you would consider using effect in user code an anti pattern

Agreed. So far it has been an anti-pattern-like for me, because as I pointed out - didn't use it.

If people start using angular with signals this mindset will probably change

If most devs have the same experience as me where they don't need toObservable, the angular team should declare openly that toObservable exists only and only for interop purposes to help with incremental migration to signals. Maybe that'll ensure that the current mindset does not change. But it's too early to do that. There's nothing wrong with change - maybe devs will come up with a better way to do things?

Which is why having a sync scheduler for it is a good thing to have - it'll allow the community to experiment more. We have nothing to lose, after all - either we discover a better pattern for data-flow that wasn't possible with just observables, but if not, the current way is good enough.