Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 27 08:12
    jakovljevic-mladen commented #7167
  • Jan 27 04:00
    benlesh commented #7167
  • Jan 26 23:56

    benlesh on master

    docs(readme): fix number versio… (compare)

  • Jan 26 23:56
    benlesh commented #7174
  • Jan 26 23:56
    benlesh closed #7174
  • Jan 26 22:38
    fabricio opened #7174
  • Jan 26 08:30

    jakovljevic-mladen on 7.x

    docs(exhaustAll): fix marble di… (compare)

  • Jan 25 22:44
    raveclassic commented #7172
  • Jan 25 22:43
    raveclassic commented #7172
  • Jan 25 22:41
    demensky opened #7173
  • Jan 25 21:58
    demensky commented #7170
  • Jan 25 21:55
    demensky synchronize #7170
  • Jan 25 21:54
    demensky synchronize #7170
  • Jan 25 17:28
    demensky commented #7170
  • Jan 25 17:27
    demensky ready_for_review #7170
  • Jan 25 17:27
    demensky synchronize #7170
  • Jan 25 17:17
    demensky converted_to_draft #7170
  • Jan 25 17:15
    benlesh commented #7170
  • Jan 25 17:12
    benlesh commented #7172
  • Jan 25 15:54
    raveclassic edited #7172
Jorrit
@jorrit-wehelp
so... use switchMap...? ;p
not sure what dispatchChanges does, but does look a bit suspicious. Whatever is does should probably just be directly chained off onDispatchChange obs :/
Lodewijk Wensveen
@lwensveen
It does all kinds of calculations with dates and stuff
I don't understand how to do this
Jorrit
@jorrit-wehelp
make the calculation observable, then .switchMap(dateChanges => dispatchChangesAsObservable(dateChanges) ?
Lodewijk Wensveen
@lwensveen
Nah my editor has some weird issue where it tries to force switchmap as a async function
Dorus
@Dorus
Rxjs is for async actions, not for canceling sync calculations
And you already have debouceTime so you already cancel quit succeeding requests
Lodewijk Wensveen
@lwensveen
It's a bit weird
there's this subject that's being nexted from a input
    this.onChangeHourChanged.pipe(
      distinctUntilChanged(),
      takeUntil(this.destroyed$),
    ).subscribe((hour) => {
      const type = DateTimeType[this.dateTimeType];
      console.log('HourChanged');

      this.currentDateTime.set({
        hour,
      });

      this.time = this.setTime(this.dateFilterValidatorService.setDate(type, this.currentDateTime));
      this.writeValue(this.time);
    });
then it calls this setDate from the service
this.onDispatchChanges.next(changes);

    this.onDispatchChanges.pipe(
      debounceTime(600),
      distinctUntilChanged(),
    ).subscribe(dateChanges => {
      this.dispatchChanges(dateChanges);
    });
Then in there it does this
I supppose it's being done like this so you can have the debounce?
Dorus
@Dorus
WHy do you subscribe after you next?
Is it a replay/behavior subject?
Lodewijk Wensveen
@lwensveen
nah it's just a regular subject
Dorus
@Dorus
You should only subscribe once and do it before you call next usually.
Ok regualar subject will forget about your next call, so that subscribe will not receive it. Just saying
common mistake (and a reason why you should avoid subjects)
Lodewijk Wensveen
@lwensveen
But then it will never receive data?
Dorus
@Dorus
yes it will only receive data that has been emitted from the subject after you subscribe.
Lodewijk Wensveen
@lwensveen
Which is none? :S
Dorus
@Dorus
Anyway this is unrelated to your cancel question (that i still do not quite understand)
Lodewijk Wensveen
@lwensveen
rxjs always works great till it doesn't
If I log inside that subscribe it logs like 3 times
at random really
Dorus
@Dorus
then you are calling the subject from somewhere
Lodewijk Wensveen
@lwensveen
Seems it doesn't clear it or something
Dorus
@Dorus
you could add tap() with a log in a few places to see wht's going trough it at each step
Lodewijk Wensveen
@lwensveen
But anyways this is too confusing for me, normally it makes sense but this is really strange, so I might just rewrite it using promises or something
Yeah that's what I did but see ^
Anyways it's still not clear to me what you meant with the next and the pipe?
A subject needs data, so you need to call next, or init it as a behavioursubject?
Dorus
@Dorus
A subject just forwards the next call to any current subscribers when you call next on it.
Lodewijk Wensveen
@lwensveen
Yes correct
Then how would I do that pipe etc without calling next?
Dorus
@Dorus
A subject is a hot primitive, it's both a observer and observable and it contains live data, other than say a cold observable like of(changes) that only holds one value and replays it each time you subscribe. Creating a new execution context each time you do.
If you use a subject, you should subscribe first and call next on it later
It's like, turn on the radio before you broadcase something, else you wont hear it.
Lodewijk Wensveen
@lwensveen
Ahh like that
Dorus
@Dorus
It's the biggest difference between promises and observable. Promises are eager, observable lazy. So with observable nothing happens till you subscribe.
Promises start running right away and store their result.
Aaron Brewer
@spaceribs

Hey friends, I've been exploring combining the concept of "Behavior Trees" (https://en.wikipedia.org/wiki/Behavior_Trees) with RxJS, and this revealed to me a combiner that I don't think currently exists, so I wanted to discuss if that's the case and if I should put up a PR to add such a combiner.

The most basic behavior tree at minimum contains an AND (sequence) combiner and an OR (selector) combiner. AND combiners run their children in sequence, and stop running if there are any failures. An AND combiner is actually very easy to translate to RxJS, it's literally just a concat.

An OR combiner instead runs it's children until success, and only fails if all it's children fail to return success. This is actually very similar to onErrorResumeNext except for the following attributes:

  • When all selectors are exhausted, throw an error.
  • Stop executing when any observable completes.

The actual code for the combiner is below:

export function selector<T, R>(
  ...sources: Array<
    | ObservableInput<any>
    | Array<ObservableInput<any>>
    | ((...values: Array<any>) => R)
  >
): Observable<R> {
  if (sources.length === 0) {
    return throwError(new Error("No selections were successfully executed."));
  }

  const [first, ...remainder] = sources;

  if (sources.length === 1 && Array.isArray(first)) {
    return onErrorResumeNext(...first);
  }

  return new Observable((subscriber) => {
    const subNext = () =>
      subscriber.add(selector(...remainder).subscribe(subscriber));

    return from(first).subscribe({
      next(value) {
        subscriber.next(value);
      },
      error: subNext,
      complete: () => {
        subscriber.complete();
      },
    });
  });
}

Should I open a PR or am I recreating/reopening a discussion that has already occurred?

also, some marble tests I've made to describe the the intended output:
  it("finds the first successful selection from a set.", () => {
    const firstObs$ = cold("--#");
    const secondObs$ = cold("--z--#");
    const thirdObs$ = cold("--x--y|");
    expect(selector(firstObs$, secondObs$, thirdObs$)).toBeMarble(
      "----z----x--y|"
    );
  });

  it("completes on the first successful selection.", () => {
    const firstObs$ = cold("--y#");
    const secondObs$ = cold("--z--|");
    const thirdObs$ = cold("--x--#");
    expect(selector(firstObs$, secondObs$, thirdObs$)).toBeMarble("--y--z--|");
  });

  it("errors if no selections are successful", () => {
    const firstObs$ = cold("--y#");
    const secondObs$ = cold("z--#");
    const thirdObs$ = cold("--x--#");
    expect(selector(firstObs$, secondObs$, thirdObs$)).toBeMarble(
      "--yz----x--#"
    );
  });
Dorus
@Dorus

@spaceribs A better place to reach the devs is slack or github. The usual response is to make a separate packages to combines with RxJs. That said they might be enthusiastic about this idea depending on how lightweight it can be added.

Also while i'm not familiar with behavior tree's myself, i do like to add RxJs is for multi value sequences and error is a rare item to emit. I'm not sure how that combines with behavior tree's.

That said, i do think what you describe is some unique behavior not easily combined with existing operators. Indeed AND could be concat or merge, but what you describe for OR (stop when any completes, error when all error) is not something i can easily produce from existing operators and sounds like a quite useful one.

Do remember that because of RxJs async nature, it would be interesting to have these operators you describe in both parallel (like merge) and sequential (like concat) flavor. Especially when you work with live data, onErrorResumeNext and concat will not work.

Ps. I just tought up of a way to get what you aim for using existing operators. onErrorResumeNext already statisfies the stop requirement, and you can easily add the error requirement by not using onErrorResumeNext on the last observable in line.
Now i'm pondering how to make a similar operator for the parallel case :D (as well as a nicer one that emits all previous errors when the last source fails)

Dominic Watson
@intellix
struggling to make something in RxJS and wondering if rubber ducking will help me
so basically, in an ideal world fromEvent(window, 'orientationchange') would emit a new width/height, but as it stands, it emits before the width/height have actually changed and it seems the only way to actually know when the orientation has changed, is to use interval hacks
so what I'm trying to create is an observable that emits when it's ACTUALLY changed by jumping into a timer loop and emitting when so