A bit unusual to use the $ suffix on a promise. Besides, toPromise() is deprecated in RxJS7.

Yep, good catch - fixed.

Angular's on RxJS 6 though, so no fancy latestValueFrom for us.

What stoping you from moving to a higher version of Rxjs?

Google uses RxJS 6 internally, so Angular needs to build with it.

We could (and probably will) upgrade to using 7, but we'd still need to be compatible with 6, so it's not been a priority.

Do we want to mention signals explicitly here? I guess long-term we want to put other non-signal, RxJS related stuff here.

Do we want to mention signals / reactivity explicitly here? I guess long-term we want to put other non-signal, RxJS related stuff here.

Do we need explicit peer dep on zone.js?

@alxhub Can you explain please this part please?
I mean it was a rxjs-interop package, probably the plan was @angular/rxjs-interop.
Now as I see, rxjs-interop will be the part of core, so zone.js is still will be a dependency there. As I heard, signals are advertised as zoneless solutions, which is currently the only (main) reason for me why we should use them.
I would like to understand that this pull request is just a step forward or there are other reason why we still need zone.js.

I think having another npm package as @angular/rxjs-interop or something is better until zone.js cannot be eliminated from core. In long term I agree, it should be in core library.

I find it surprising that the type of the signal and initial state are different. What is the use-case that we are targeting here?

My guess is that it's mainly useful when you have an Observable<Something> and you want null or undefined as default value.

implementation of rxjs firstValueFrom and lastValueFrom also have different type for defaultValue.
But maybe instead of initialValue rxjs defaultValue is more fitting as it is not only initial - so in a state of suspense but also if observable completed without any value too. Also keeping rxjs config approach can be useful in future if we would like to extend this config,

export interface FirstValueFromConfig<T> {
  defaultValue: T;
}

export function firstValueFrom<T, D>(source: Observable<T>, config: FirstValueFromConfig<D>): Promise<T | D>;
export function firstValueFrom<T>(source: Observable<T>): Promise<T>;

Then again If the source Observable does not complete or emit, you will end up with a Promise that is hung up, and potentially all of the state of an async function hanging out in memory,
So they differentiate those two states and do not throw nor return a default value if there is no emission before read.

Initial value could also be achieved by using startWith operator but that would not work if the subsequent emission would be empty.

it's mainly useful when you have an Observable and you want null or undefined as default value.

But this is strange since having null as a default value means that anyone can read this value so it should be legitimate type of a signal. In this case it would be T | null

Defaulting to null | undefined instead of initialValue: U would be | async pipe | null problem again

Just throwing in my 2 cents here...

RxJS doesn't distinguish between observables that emit immediately vs asynchronously. So I don't think consumers of observables should rely on knowledge about when they're going to emit. This could cause unexpected errors. Much better would be to type it as T | null always, but optimally let devs pass in a type argument (or infer from initial state passed in) if they happen to know 100% that the observable emits immediately. But in my opinion even this explicit type parameter is dangerous because you could modify the observable upstream and TypeScript could not prevent a runtime error. And I don't see a significant difference between null and undefined here, but I haven't thought that through carefully.

The only way safe way out of this TypeScript awkwardness is if the observables themselves contained knowledge about whether they are going to emit immediately or not.

I was thinking about this before, not sure if its possible for the given use case, but you could introduce a 'loading' object which is static and use it as a type. That way you could have a difference between loading, null, undefined and T.

What you would have to do if handle then that type in every pipe in angular etc. Maybe a overkill but just wanted to point the idea out.

Why is it computed? I guess there are 2 things we need to do:

• make sure that it is not mutable;
• it is branded (?)

Normally a simple function would be enough, I guess this is about branding?

What dose it mean 'branded'?

What dose it mean 'branded'?

https://twitter.com/mattpocockuk/status/1625173884885401600

nit: should it be RuntimeError?

nit: TODO is left in. This needs a runtime error code.

thinking out loud: those tests will fail when we change the timing of effects, right? Which kind of rises the question of testing patterns for effects. A separate discussion that we should have.

As an alternative we could have written those tests with just a signal and / or computed and just assert that new value is available. We might leave a test or two with effect but IMO ones based on just signals would be more readable.

nit: TODO is left in. This needs a runtime error code.