늦게 온 리더를 위한 라이브 현재 값

우열 없음 async

요구사항

온도 피드가 고정 스케줄로 업데이트를 밀어 보냅니다. 대시보드는 첫 세 업데이트가 이미 지나간 뒤에야 접속합니다 — 그래도 현재 값(합류 시점의 최신인 19.1 °C)을 즉시 보여 준 뒤, 이후의 모든 업데이트를 보여 줘야 합니다. 스케줄은 코드에 시뮬레이션되어 있습니다; 두 버전 모두 예상 출력 아래에 표시된 줄들을 출력해야 합니다.

예상 출력
joined late, current: 19.1
update: 19.5
update: 20.0

나란히 보기

RxDart

FxDart

차이가 나는 이유

다르지 않습니다. "누가 나타나든 리플레이되는 최신 값"은 공유된 멀티캐스트 상태이고, fxdart에도 그것을 위한 전용 객체가 있습니다: LiveValueBehaviorSubject를 그것을 정의하는 동작만 남기고 줄인 것입니다 — 센서가 쓰는 싱크, 읽을 수 있는 .value, 그리고 늦게 온 구독자가 먼저 가장 최근 값을 받고 그다음 라이브 업데이트를 받는 피드. 두 패널 모두 "업데이트 넣기, 늦게 구독하기, 수집하기"입니다 — 손수 캐시한 변수도, 여분의 캐싱 리스너도 없습니다.

이것이 fxdart의 이벤트 레이어가 push 쪽을 위해 Rx의 접근을 흡수한 모습입니다: LiveValue.livefxEvents 체인을 돌려주는데 — 평범한 브로드캐스트 Stream 위의 얇은 래퍼라 rxdart를 포함해 어떤 것과도 충돌하지 않습니다 — 값별 처리가 자라면 .pull()이 타입 있는 pull 파이프라인으로 건너갑니다. RxDart의 subject 계열과 연산자 카탈로그는 여전히 훨씬 큽니다; 최신-값-그다음-라이브 자체에 관해서는 두 패널이 동등합니다: 무승부입니다.

벤치마크

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