Społeczność

Discord

meet.js Poland

Dołącz do rozmowy

Grupa na Facebooku

JavaScript i front-end
Białystok

Dołącz do grupy

Kiedy odbyło się
pierwsze spotkanie meet.js
w Białymstoku?

meet.js Białystok #2

24 lutego 2015

JavaScript Białystok #1

20 stycznia 2015

Prelegent na scenie podczas Hello Angular na JavaScript Białystok #1

Sala pełna uczestników JavaScript Białystok #1

Uczestnicy JavaScript Białystok #1 przy stolikach

Widok sali i sceny od tyłu na JavaScript Białystok #1

Uczestnicy JavaScript Białystok #1 słuchający prezentacji

Klimat przy barze i stolikach na JavaScript Białystok #1

Publiczność skupiona na prelekcji na JavaScript Białystok #1

Historia meet.js Białystok

62 spotkania · 7 miejsc · 2015–2026

2015

2016

2017

2018

2019

2020

#32 29.01
#33 26.02
#34 25.03

2021

2022

2023

2024

2025

2026

Zmiana Klimatu

SoftwareHut

HACKLAG

Explorer HQ

Instapage Poland

6-Ścian PUB Sześcian

Klub GWINT

Odwołane (#34, #38)

Zawsze gdzieś się przewijałem

Archiwalne zdjęcie uczestników spotkania JavaScript

Poprzednie wystąpienia

Jak zostać mobile deweloperem w 1 dzień

17. lipiec 2016 • meet.js #8

Trening na redukcję: jak spalić kilobajty

17. maj 2017 • meet.js #15

RxJS Operatory, które znasz, ale bałeś się zagadać

Paweł Kondraciuk

Sr. JavaScript Developer

ReactiveX jest wszędzie

Jedna idea. Wiele języków.

C# Java JavaScript Kotlin Swift Scala C++ Python Go Ruby PHP Dart Groovy Clojure Objective-C F#

Jakie znasz
operatory RxJS?

map tap filter switchMap

Jak czytać animacje?

A: źródło B: odbiorca

unsubscribe

Odbiorca rezygnuje.
Połączenie znika.

complete

Koniec strumienia.
Bez błędu.

error

Koniec strumienia.
Z błędem.

in progress

Praca trwa

Wartość płynąca
do odbiorcy

To legenda dla kolejnych diagramów. A oznacza źródło, B odbiorcę. Czarna kreska pokazuje połączenie: przy subscribe wydłuża się od odbiorcy B do źródła A, a przy unsubscribe skraca się i znika. Sama subskrypcja nie musi uruchamiać producenta, na przykład przy już działającym źródle hot.

Przy complete i error linia skraca się i znika od źródła A do odbiorcy B: zielona przy complete i czerwona przy error. To kierunek przeciwny do unsubscribe. Tylko klocek odbiorcy B ma kolor zakończenia; źródło A zachowuje swój kolor. Oba powiadomienia są terminalne: ta subskrypcja nie dostanie już kolejnych wartości. Unsubscribe to rezygnacja odbiorcy i samo nie wywołuje jego callbacku complete. Nie musi również zatrzymać współdzielonego producenta.

Blok HTTP z rosnącym paskiem na dole oznacza pracę w toku (in progress). Pasek jest umowną ilustracją czasu pracy, nie pomiarem postępu prawdziwego żądania HTTP. Kółka z liczbami pokazują next, czyli wartości. Animacje legendy powtarzają się co sześć sekund, aby można było spokojnie je omówić. Każda pętla przedstawia nowy przykład, a nie wznowienie zakończonej subskrypcji. Ruch jest ilustracją, nie opóźnieniem RxJS.

Operator to funkcja

Skąd płyną wartości?

Co uruchamia pracę?

Cold vs hot — skąd B zaczyna liczyć?

Dwie subskrypcje — bez share czy z share?

A jeśli wartością jest Observable?

concatMap — Po kolei

mergeMap — Równocześnie

switchMap — Najnowsza subskrypcja

exhaustMap — Jestem zajęty

Czy ten sam identyfikator wymaga kolejnego HTTP?

Czekać na ciszę czy aktualizować w trakcie?

Jeden user$. Dwie subskrypcje.

Najpierw pokaż dwie zwykłe subskrypcje A i B. http$ oznacza zimne Observable HTTP, np. ajax.getJSON z rxjs/ajax. Obie subskrypcje zaczynają się przed odpowiedzią. share stosujemy raz do wspólnej instancji user$. Dopiero po porównaniu odnieś odbiorców do Angular async pipe albo subscribe w React useEffect ze sprzątaniem przez unsubscribe. W React zachowaj stabilną instancję user$ poza komponentami; nie twórz osobnego share w każdym efekcie. AsyncPipe zarządza własną subskrypcją, ale nie dodaje współdzielenia. share nie jest trwałym cache.

Tryb ręczny: prawo uruchamia kolejny postój, lewo cofa. Klik po ostatnim pytaniu włącza AUTO na tym samym slajdzie. MAIN zatrzymuje wynik; dodatki mogą powtarzać pokaz. W AUTO lewo / prawo zmienia slajdy. M: tryb ręczny/auto, U: sterowanie, A: automat/pauza, R: od początku.

B przychodzi po odpowiedzi. Co dostanie?

Jeden błąd. Czy następny klik zadziała?

Porównaj położenie catchError: osobny operator za switchMap albo operator wewnątrz ramki każdego HTTP. http$ jest zimnym Observable, a każde kliknięcie tworzy jego nową subskrypcję. Ręczne postoje pokazują pracę A, błąd i wynik zastępczy []. W obu wariantach catchError subskrybuje of([]), które emituje i kończy się. Na zewnątrz kończy się cały wynik, a subskrypcja klik$ znika. Klik B nadal może wystąpić w źródle, lecz nie uruchamia HTTP B. Wewnątrz kończy się tylko inner A: kolejne kliknięcie uruchamia HTTP B z własnym catchError i przekazuje wynik B. Przerywana linia wskazuje zakres prac tworzonych przez switchMap; nie jest subskrypcją. Nie sugeruj, że każdy zewnętrzny catchError zawsze kończy wynik: tutaj wynika to z wyboru of([]).

Widok zniknął. Dlaczego timer nadal działa?

100 elementów. Skąd wziąć ownerFullName?

Jedna pętla, jeden microtask

Wspólna kolejka HTTP, własny komplet wyników

Dwa resolveMany([A,B,C]) i resolveMany([C,D,E]) korzystają z resolve(id): cache, mapa in-flight albo requestSubject. Wspólne C deduplikuje mapa in-flight, nie bufferTime. Długowieczna subskrypcja requestSubject.pipe(bufferTime(250, null, maxBatchSize, asyncScheduler), filter(xs => xs.length > 0), map(dedupe), mergeMap(batch => httpFetch(batch)), takeUntilDestroyed()) wykonuje fizyczny HTTP. W pokazie maxBatchSize=10, pięć unikalnych ID mieści się w jednym oknie. Limit rozmiaru może zamknąć paczkę wcześniej; okno 250 ms zaczyna się przy otwarciu bufora, nie przy pierwszym ID. To osobna warstwa względem microtaska. mergeMap bez concurrency nie ogranicza równoległości ani rate limitu. Odpowiedzi są rozdzielane do oczekujących resolve(id), które emitują i kończą się. Każdy forkJoin dostaje komplet własnych wyników jako Map; enrichment scala je w store i widoki reagują. Kontrakt przykładu: resolveMany([]) zwraca of(new Map()); samo forkJoin([]) kończy bez next. Błąd fizycznej paczki jest przekazywany wszystkim czekającym na jej ID, kończy zależny forkJoin, usuwa in-flight i nie zapisuje sukcesu do cache/store. Niezależne paczki mogą działać dalej; niszczenie kontekstu sprząta subskrypcję i oczekujące żądania.

Cztery pytania przed kolejnym pipe

Pytania?

Dodatkowe przykłady

source$: complete. Czy wynik też kończy?

Dodatkowe przykłady

100 zadań. Ile naraz?

Dodatkowe przykłady

Cztery sposoby ograniczania emisji

Dodatkowe przykłady

Kto ma prawo uruchomić pracę?

Dodatkowe przykłady

Jeden wynik w kilku miejscach widoku

Dodatkowe przykłady

A co z signals?

Dodatkowe przykłady

Kiedy odczytujesz wartość?

Dodatkowe przykłady

first() i take(1) — to samo?

Dodatkowe przykłady

Potrzebuję wszystkich zdarzeń — w paczkach

Dodatkowe przykłady

Sprzątanie także po odsubskrybowaniu

Dodatkowe przykłady

Czekam na komplet zakończonych żądań

Dodatkowe przykłady

Pierwsze z pierwszym. Drugie z drugim.

Dodatkowe przykłady

Kilka powodów do odświeżenia

Dodatkowe przykłady

Co zmieniło się od poprzedniej wartości?

Dodatkowe przykłady

Społeczność

meet.js Poland

JavaScript i front-endBiałystok

Kiedy odbyło siępierwsze spotkanie meet.jsw Białymstoku?

meet.js Białystok #2

JavaScript Białystok #1

Historia meet.js Białystok

Zawsze gdzieś się przewijałem

Poprzednie wystąpienia

Jak zostać mobile deweloperem w 1 dzień

Trening na redukcję: jak spalić kilobajty

RxJS Operatory, które znasz, ale bałeś się zagadać

Paweł Kondraciuk

ReactiveX jest wszędzie

Jakie znaszoperatory RxJS?

A share?

Jak czytać animacje?

subscribe

unsubscribe

complete

error

in progress

Operator to funkcja

Skąd płyną wartości?

Co uruchamia pracę?

Cold vs hot — skąd B zaczyna liczyć?

Dwie subskrypcje — bez share czy z share?

A jeśli wartością jest Observable?

concatMap — Po kolei

mergeMap — Równocześnie

switchMap — Najnowsza subskrypcja

exhaustMap — Jestem zajęty

Czy ten sam identyfikator wymaga kolejnego HTTP?

Czekać na ciszę czy aktualizować w trakcie?

Jeden user$. Dwie subskrypcje.

B przychodzi po odpowiedzi. Co dostanie?

Jeden błąd. Czy następny klik zadziała?

Widok zniknął. Dlaczego timer nadal działa?

100 elementów. Skąd wziąć ownerFullName?

Jedna pętla, jeden microtask

Wspólna kolejka HTTP, własny komplet wyników

Cztery pytania przed kolejnym pipe

Pytania?

share — wspólne wykonanie

source$: complete. Czy wynik też kończy?

100 zadań. Ile naraz?

Cztery sposoby ograniczania emisji

Kto ma prawo uruchomić pracę?

map(expensive) — raz czy dla każdego?

Czy expensive jest przed share?

Jeden wynik w kilku miejscach widoku

A co z signals?

Kiedy odczytujesz wartość?

first() i take(1) — to samo?

Potrzebuję wszystkich zdarzeń — w paczkach

Sprzątanie także po odsubskrybowaniu

Czekam na komplet zakończonych żądań

Pierwsze z pierwszym. Drugie z drugim.

Kilka powodów do odświeżenia

Co zmieniło się od poprzedniej wartości?

JavaScript i front-end
Białystok

Kiedy odbyło się
pierwsze spotkanie meet.js
w Białymstoku?

Jakie znasz
operatory RxJS?