검색창 디바운스하기

우열 없음 async

요구사항

사용자가 f, fx, fxd를 빠른 연타로 입력하고, 잠시 멈췄다가, fxdart를 입력합니다. 타이핑이 160 ms 동안 잠잠했을 때만 검색하세요 — 그래서 정확히 두 번의 검색이 실행되고(fxd와 fxdart) — 각 결과를 출력합니다. 키 입력 스케줄은 코드에 시뮬레이션되어 있습니다; 두 버전 모두 예상 출력 아래에 표시된 줄들을 출력해야 합니다.

예상 출력

3 results for "fxd"
12 results for "fxdart"

나란히 보기

RxDart

FxDart

차이가 나는 이유

다르지 않습니다. 이것은 가장 순수한 형태의 push 문제이고 — 흥미로운 것은 값이 아니라 값이 언제 도착하기를 멈추는가입니다 — 두 패널 모두 같은 방식으로 말합니다: 이벤트 스트림을 160 ms로 디바운스하고, 살아남은 각 쿼리를 검색하고, 수집합니다. RxDart는 그것을 debounceTime이라고 쓰고; fxdart는 fxEvents(...).debounce(...)라고 씁니다. 연산자 대 연산자로 두 체인은 동등하며, 닫힐 때 흘려보내는 트레일링 값까지 같습니다.

이는 의도된 것입니다: fxdart의 이벤트 레이어는 push 쪽을 위해 Rx의 접근을 흡수했습니다. fxEvents는 평범한 Dart Stream 위의 얇은 래퍼 체인으로 — 결코 extension이 아니어서 rxdart를 포함해 어떤 것과도 충돌하지 않습니다 — pull 파이프라인이 정당하게 거절했던 시간 기반 연산자들에게 집을 마련해 줍니다. RxDart의 연산자 카탈로그는 여전히 훨씬 큽니다; fxdart는 일상적인 push 동사들을 다루고 거기서 멈춥니다. 그리고 디바운스된 쿼리들이 타입 있는 요구 주도 작업 — 순서 있는 동시 fetch, 타입 있는 에러 처리 — 으로 이어져야 할 때는 .pull()이 FxAsync 파이프라인으로 돌아가는 문입니다.

벤치마크

이 예제에는 벤치마크가 없습니다. 이 연산자는 처리한 일의 양이 아니라 흘러간 시간으로 정의됩니다. 양쪽 모두 똑같은 시간 창을 기다리므로, 막대는 두 라이브러리가 아니라 Dart의 타이머를 재게 됩니다. 시간 창을 줄여도 해결되지 않습니다 — 그러면 한 번의 이벤트 폭주에서 몇 개의 값이 나오는지가 머신 속도에 좌우되고, 두 구현이 같은 결과를 냈는지 대조할 수 없게 되기 때문입니다. 타이밍 연산자로 만들어진 예제들을 측정하지 않고 두는 이유가 이것입니다. 지연이 그저 I/O를 흉내 낼 뿐인 예제들은 그 지연을 0으로 두고 벤치마크합니다.