filter() 之后的 takeUntil() 的行为与管道中的 take(n) 不同

Question

this.activatedRoute.queryParamMap
      .pipe(
        // activatedRoute.queryParamMap emits null values first. So let's avoid it
        filter((paramMap) => paramMap && paramMap.keys.length > 0),
        // unsubscribe immediately if some params are found
        take(1),
        // If the params are really empty, filter will never pass. So let's unsubscribe after sometime
        takeUntil(timer(1000)),
        delay(1),
        combineLatestWith(this.sortableColumns$),
      )
      .subscribe(([paramMap, sortableColumns]) => {
        console.log("paramMap")
        this.setTableOptionsFromUrl(paramMap, sortableColumns);
      });

我有上面的代码。

• 因此，仅当过滤器在源有效发射后通过时（仅当至少有一个 paramMap 时），take(1) 才会从可观察源取消订阅
• takeUntil 也出现在过滤器之后，但一旦计时器发出，无论过滤器是否通过，它都会从源取消订阅

我的问题是，

• 如果过滤器阻塞管道直到它通过，它是否也应该阻塞 takeUntil ？
• 如果这是预期的行为，我如何知道哪些运算符将被过滤器运算符阻止，哪些全部不会被阻止
• 如果这不是预期的行为，我们还能如何实现这一目标？

Answer 1

take(1)

在第一次发射后完成。 由于您之前有一个过滤器，因此它仅在 fiter 之后完成是合乎逻辑的。它无法知道之前会发生什么。在它之前你可能有 100 个操作员。

当通知者告诉他做什么时，

takeUntil()

完成，在本例中是 1000 毫秒后。他不在乎前后发生什么，它只是在 1000 毫秒后完成。

如果你仔细想想，这是合乎逻辑的。这些操作员或多或少独立于前后发生的事情。