Блог

«Таким образом» относится к 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);  }); }  

Идея заключается в том, что независимо от того, какие дополнительные наблюдаемые параметры необходимы дочернему компоненту для поддержки его пользовательской бизнес-логики, родительский код отделен от этого