ReactiveX

ReactiveX

Reactive Extensions for Async Programming

Member Since 7 years ago

Experience Points
0
follower
Lessons Completed
0
follow
Best Reply Awards
42
repos
Activity
Nov
29
8 hours ago
Activity icon
fork

cect3329 forked ReactiveX/RxJava

⚡ RxJava – Reactive Extensions for the JVM – a library for composing asynchronous and event-based programs using observable sequences for the Java VM.
cect3329 Apache License 2.0 Updated
fork time in 2 hours ago
started
started time in 3 hours ago
started
started time in 4 hours ago
started
started time in 4 hours ago
started
started time in 5 hours ago
started
started time in 5 hours ago
Activity icon
issue

josepot issue comment ReactiveX/rxjs

josepot
josepot

fix: race condition with Interop Observables

Description:

I'm working on a library that exposes Interop Observables and I've noticed that in some situations, depending on which package gets imported first, the user gets the following error:

TypeError: You provided an invalid object where a stream was expected. You can provide an Observable, Promise, ReadableStream, Array, AsyncIterable, or Iterable.

After some debugging I found that the culprit is this line of code:

export const observable: string | symbol = (() => (typeof Symbol === 'function' && Symbol.observable) || '@@observable')();

The problem with that code is that if it runs before the package(s) that are responsible for polyfilling Symbol.observable get evaluated, then it's already too late to polyfill Symbol.observable.

A simple solution would be to make that code lazy, so that if later on a package polyfills Symbol.observable then everything should work as it's expected:

export const observable: () => string | symbol = (() => typeof Symbol === 'function' && Symbol.observable) || '@@observable';

Which is the change that I'm proposing in this PR.

josepot
josepot

Oh, wow! I just noticed that this observable is part of the public API :scream: So, this would be a breaking change... :worried:

I think that this must be a mistake, IMO it only makes sense to expose a non lazy version of it if RxJS itself polyfills Symbol.observable like it used to do it in the past... Otherwise, it should be a function, right?

pull request

josepot pull request ReactiveX/rxjs

josepot
josepot

fix: race condition with Interop Observables

Description:

I'm working on a library that exposes Interop Observables and I've noticed that in some situations, depending on which package gets imported first, the user gets the following error:

TypeError: You provided an invalid object where a stream was expected. You can provide an Observable, Promise, ReadableStream, Array, AsyncIterable, or Iterable.

After some debugging I found that the culprit is this line of code:

export const observable: string | symbol = (() => (typeof Symbol === 'function' && Symbol.observable) || '@@observable')();

The problem with that code is that if it runs before the package(s) that are responsible for polyfilling Symbol.observable get evaluated, then it's already too late to polyfill Symbol.observable.

A simple solution would be to make that code lazy, so that if later on a package polyfills Symbol.observable then everything should work as it's expected:

export const observable: () => string | symbol = (() => typeof Symbol === 'function' && Symbol.observable) || '@@observable';

Which is the change that I'm proposing in this PR.

started
started time in 7 hours ago
started
started time in 7 hours ago
Nov
28
1 day ago
started
started time in 10 hours ago
started
started time in 10 hours ago
started
started time in 11 hours ago
started
started time in 11 hours ago
started
started time in 11 hours ago
started
started time in 12 hours ago
started
started time in 14 hours ago
started
started time in 16 hours ago
Activity icon
fork

j5s forked ReactiveX/RxGo

⚡ Reactive Extensions for the Go language.
j5s MIT License Updated
fork time in 19 hours ago
started
started time in 19 hours ago
started
started time in 19 hours ago
started
started time in 20 hours ago
started
started time in 21 hours ago
open pull request

josepot wants to merge ReactiveX/rxjs

josepot
josepot

Feature: AbortSignal support first value from last value from

feat(lastValueFrom): Adds support for cancellation with AbortSignal.

Similar to the update to firstValueFrom. This adds a configuration option to unsubscribe from the underlying subscription with an AbortSignal. If aborted with a signal, the returned promise will reject with an AbortError.

resolves #6442

feat(firstValueFrom): now supports AbortSignal cancellation

Adds a feature to the firstValueFrom config to support passing an AbortSignal that can be used to unsubscribe from the underlying subscription. This will result in the returned promise rejecting with an AbortError, which is an error type belonging to the library at this point. This is because there is no consistent error type to throw across all supported runtimes that the user could check for.

related #6442

josepot
josepot

@benjamingr thanks for your response! I ended up spending a lot of time trying to understand the history behind AbortController, after I read all the comments in the issue that you shared... Let's just say that I have a lot of thoughts and opinions about it :sweat_smile:. However, in order to stay constructive, I will keep those thoughts to myself and I will try to propose a solution for RxJS that I think that should work for all users, despite the current (and hopefully temporary) misalignment between the DOM spec and the NodeJS API:

  • RxJS should keep its AbortError class as an internal implementation detail, since AFAIK doing e instanceof AbortError has never been the recommended way of identifying the AbortError exception.

  • When the onAbort event happens, then RxJS should first check whether signal.hasOwnProerty('reason'), and then it should reject using that reason if it exists, otherwise it should use a new instance of its internal AbortError as a fallback.

Rejecting abortions this way would guarantee that RxJS implementation works for both kinds of ursers: DOM and NodeJS. Given the current state of things, I think that's the most sensible approach to stay compliant with the current misalignment.

pull request

josepot merge to ReactiveX/rxjs

josepot
josepot

Feature: AbortSignal support first value from last value from

feat(lastValueFrom): Adds support for cancellation with AbortSignal.

Similar to the update to firstValueFrom. This adds a configuration option to unsubscribe from the underlying subscription with an AbortSignal. If aborted with a signal, the returned promise will reject with an AbortError.

resolves #6442

feat(firstValueFrom): now supports AbortSignal cancellation

Adds a feature to the firstValueFrom config to support passing an AbortSignal that can be used to unsubscribe from the underlying subscription. This will result in the returned promise rejecting with an AbortError, which is an error type belonging to the library at this point. This is because there is no consistent error type to throw across all supported runtimes that the user could check for.

related #6442

started
started time in 22 hours ago
started
started time in 23 hours ago
started
started time in 23 hours ago
started
started time in 1 day ago
Activity icon
fork

blairt001 forked ReactiveX/RxJava

⚡ RxJava – Reactive Extensions for the JVM – a library for composing asynchronous and event-based programs using observable sequences for the Java VM.
blairt001 Apache License 2.0 Updated
fork time in 1 day ago
Previous