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
28
14 hours ago
Activity icon
fork

j5s forked ReactiveX/RxGo

⚡ Reactive Extensions for the Go language.
j5s MIT License Updated
fork time in 2 hours ago
started
started time in 2 hours ago
started
started time in 2 hours ago
started
started time in 3 hours ago
started
started time in 4 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 5 hours ago
started
started time in 6 hours ago
started
started time in 6 hours ago
started
started time in 7 hours 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 10 hours ago
started
started time in 12 hours ago
started
started time in 12 hours ago
started
started time in 12 hours ago
Nov
27
1 day ago
pull request

yunuseon merge to ReactiveX/rxjs

yunuseon
yunuseon

fix: takeWhile Boolean constructor types

I think that the typings for the Boolean constructor of takeWhile are off... For instance, I think that the following dtslint test:

const c = of(
  false as const,
  0 as const,
  "hi" as const,
  -0 as const,
  0n as const,
  "" as const,
  null,
  undefined
).pipe(takeWhile(Boolean)); // $ExpectType Observable<false | "" | 0 | 0n | "hi" | null | undefined>

should expect this, instead:

const c = of(
  false as const,
  0 as const,
  "hi" as const,
  -0 as const,
  0n as const,
  "" as const,
  null,
  undefined
).pipe(takeWhile(Boolean)); // $ExpectType Observable<"hi">

The goal of this PR is to make the Boolean constructor typings of takeWhile (when the inclusive flag is set to false) consistent with the typings of filter.

Activity icon
issue

yunuseon issue comment ReactiveX/rxjs

yunuseon
yunuseon

Feature: Add getValue() in ReplaySubject to get the last emitted value

I'm a first-time contributor (not a consumer) to RxJS. Pardon my lack of understanding.

Description:

Just like BehaviorSubject, this PR will add a method getValue() in ReplaySubject so that the owner can always get the last emitted value (if not, returns null). This change makes the ReplaySubject usable like a state (maybe this can be a different *Subject class itself).

Once this MR is approved, I'll update the documentation.

yunuseon
yunuseon

Hey @sagrawal31 , unfortunately a getValue() Method would only make sense for a ReplaySubject with the buffer of 1. ReplaySubjects with a buffer size of 1 are very similiar to BehaviorSubject, from the docs:

https://rxjs.dev/api/index/class/ReplaySubject

BehaviorSubject is similar to new ReplaySubject(1), with a couple fo exceptions:

  1. BehaviorSubject comes "primed" with a single value upon construction.
  2. ReplaySubject will replay values, even after observing an error, where BehaviorSubject will not.
started
started time in 15 hours ago
started
started time in 20 hours ago
started
started time in 20 hours ago
started
started time in 20 hours ago
started
started time in 20 hours ago
Activity icon
issue

steuke issue ReactiveX/RxPY

steuke
steuke

Is this the expected behavior of the `window_with_count`-operator?

I have been trying to wrap my head around the window_with_count-operator, but it just does not do what I would expect from looking at the marble-diagram in the documentation. Here is an example with expected and actual output:

Minimal example

from rx import operators, from_


def sliding_window_example(window_size: int):
    values = range(99, 103)
    source = from_(values).pipe(
        operators.window_with_count(count=window_size, skip=1),
        operators.do_action(on_next=lambda x: print(f"New window")),
    )
    print("Subscribing to source")
    source.subscribe(lambda the_window: the_window.subscribe(print))


if __name__ == "__main__":
    sliding_window_example(window_size=3)

Expected output

I would expect each window to emit the values as they appeared in the source observable:

Subscribing to source
New window
99
New window
99
100
New window
99
100
101
New window
100
101
102
New window

Actual output

But instead, each window seems to emit the most recent value repeatedly:

Subscribing to source
New window
99
New window
100
100
New window
101
101
101
New window
102
102
102
New window

Questions

  1. Am I doing something wrong, or is this the expected behavior?
  2. Is there a way to achieve my expected output from the input values using the window-operator in some other way?

Thanks for taking the time! Best, Stefan

Activity icon
fork

xuzeyun1993 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.
xuzeyun1993 Apache License 2.0 Updated
fork time in 23 hours ago
started
started time in 1 day ago
started
started time in 1 day ago
Activity icon
fork

dkappdev forked ReactiveX/RxSwift

⚡ Reactive Programming in Swift
dkappdev Updated
fork time in 1 day ago
started
started time in 1 day ago
started
started time in 1 day ago
started
started time in 1 day ago
Previous