#rxjs
Вопрос:
«Таким образом» относится к of(0).pipe(withLatestFrom(obsB)...
разделу моего предполагаемого кода ниже.
Обычный способ написания этого
obsA.pipe( withLatestFrom(obsB), map(([a, b]) =gt; { // business logic return f(a,b); }) )
Моя предполагаемая альтернатива
obsA.pipe( mergeMap((a) =gt; { // marker 1 return of(0).pipe( withLatestFrom(obsB), map((_, b) =gt; { // business logic return f(a,b); }) // marker 1 }) )
Преимущество заключается в том, что код между marker 1
ними может быть извлечен в метод, который может быть предоставлен дочерним компонентом/классом. И если логика дочернего класса требует наблюдаемого C, ему не нужно изменять код в родительском. В то время как в обычном случае нам необходимо обновлять подпись всякий раз, когда в дочернем классе требуется новая наблюдаемая, которая может даже не понадобиться другому дочернему классу.
———-обновление — — — — — — — — — —
Это показывает, почему это более удобно.
Родитель
protected abstract getThing(a); ... obsA.pipe( mergeMap((a) =gt; getThing(a)) )
Ребенок X
protected getThing(a) { return of(0).pipe( withLatestFrom(obsB), map((_, b) =gt; { // business logic return f1(a, b); }); }
Ребенок Y
protected getThing(a) { return of(0).pipe( withLatestFrom(obsC, obsD), map((_, d, c) =gt; { // a different business logic return f2(a, c, d); }); }
Идея заключается в том, что независимо от того, какие дополнительные наблюдаемые параметры необходимы дочернему компоненту для поддержки его пользовательской бизнес-логики, родительский код отделен от этого
Комментарии:
1. Я имею в виду, они делают разные вещи.
mergeMap
эффективно откладываетwithLatestFrom
, поэтому он будет вести себя не совсем так же. Учтите, что вы также можете абстрагировать другой метод, если хотите, поэтому я не совсем уверен, что вы выигрываете таким образом.