각 요청에 최신 설정 도장 찍기

우열 없음 async

요구사항

앱이 API 요청 네 건을 발사하는 동안, 배경에서는 배포가 config 버전을 v1 → v2 → v3로 고정 오프셋에 맞춰 올립니다. 각 요청에는 요청이 발사된 순간 유효하던 config 버전이 찍혀야 하고 — config 상승만으로는 아무것도 내보내면 안 됩니다. 도장 찍힌 요청 네 건을 출력하세요. 두 스케줄 모두 코드에 시뮬레이션되어 있습니다; 두 버전 모두 예상 출력 아래에 표시된 줄들을 출력해야 합니다.

예상 출력
GET /orders (config v1)
GET /stock (config v2)
GET /prices (config v2)
GET /refunds (config v3)

나란히 보기

RxDart

FxDart

차이가 나는 이유

다르지 않습니다. 이것은 combineLatest의 비대칭 형제입니다 — 한 스트림이 주도하고, 다른 스트림은 참조될 뿐입니다 — 그리고 두 패널 모두 그것을 같은 이름으로 부릅니다: withLatestFrom이 요청마다 내보내되 지금까지 본 가장 신선한 config를 찍어 주고, config만 바뀔 때는 침묵합니다. 태그 병합 뼈대도, scan 폴드도 필요 없습니다 — 두 체인은 연산자 대 연산자로 동일합니다.

fxdart의 이벤트 레이어는 push 쪽을 위해 Rx의 접근을 흡수했습니다: fxEvents는 평범한 Stream 위의 얇은 래퍼 체인으로 — 결코 extension이 아니어서 rxdart를 포함해 어떤 것과도 충돌하지 않습니다. RxDart의 연산자 카탈로그는 여전히 훨씬 큽니다; fxdart는 이벤트 코어를 작게 유지하고, 값별 처리가 자라면 .pull()로 타입 있는 pull 파이프라인으로 건너갑니다. 살아 있는 스트림 하나에 다른 스트림의 최신 값을 찍는 일에서는 두 쪽이 동등합니다: 무승부입니다.

벤치마크

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