Четвертый шаг в мир RxJs: незавершенные потоки — тихие убийцы приложений

[SWATOPLUS]

По моему опыту, главная сложность RxJS в том, что все разновидности потоков сваливаются в один тип — Observable. В результате:

• есть «горячие» и «холодные» потоки;

• есть потоки, которые просто отдают единственное значение (как Promise);

• есть BehaviorSubject, который сразу возвращает текущее значение.

Было бы здорово хотя бы разделить Behavior и обычные потоки. Представьте себе:

• BehaviorObservable (наследник Observable) с полем value, которое синхронно отдает текущее значение;

• SingleObservable для одноразовых эмиссий, аналогичный Promise; // хотя зачем если есть Promise?

• …и т. д. для остальных сценариев (cold / warm).

Такая иерархия позволила бы сразу понять, чего ждать от конкретного объекта, не заглядывая в документацию.

Отдельный лайфхак для Angular-разработчиков: для HTTP запросов зачастую удобнее использовать нативные Promise — они проще по семантике и не требуют дополнительных ухищрений для единственного ответа. (Это уже не про RxJS, а про выбор инструмента в Angular.)

[t-mish]

Где-то грустит один takeUntilDestroyed

P.S. Знаю, что он относится к Angular, а не к RxJs, но в статье все крутится вокруг Angular и не нельзя упомянуть об этом операторе.