rxjs. хорошая ли практика иметь код в методе subscribe?

#rxjs #observable

#rxjs #наблюдаемый

Вопрос:

Помню, когда-то давно я нашел рекомендацию избегать любого кода в subscribe методе и вместо этого использовать каналы.

 // suppose bad
observable.subscribe(() => dosmg())

// suppose good
observable
    .pipe(tap(() => dosmg()))
    .subscribe()

Рассуждения были связаны с дрожанием дерева. Второй вариант, предложенный для лучшей оптимизации. В настоящее время я больше не могу найти эту рекомендацию, а также противоположную рекомендацию. И множество учебных материалов, с которыми я столкнулся, добавляют код в subscribe метод без объяснений. По-прежнему рекомендуется использовать каналы вместо кода в subscribe ?

1. Лучший способ — поместить код внутрь subscribe .

2. Я обычно помещаю код в subscribe, если у меня всего до 10 строк кода. Больше, чем это, и он выделяется в отдельный метод для удобства чтения.

3. Мне кажется, лучше не помещать свой код внутри subscribe, для лучшей цепочки и повторного использования вашего кода.

4. Нет, определенно нет. Вы должны думать о subscribe как «выполнить эту цепочку сейчас». Например, в tap следует ввести бизнес-логику.

5. @ritaj ваше предложение в основном противоположно тому, что представляет rxjs.

Ответ №1:

Обычно я избегаю указывать логику в subscribe .

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

Если вы добавляете логику в subscribe, это просто теряет переносимость и усложняет рефакторинг на более позднем этапе. Вот типичный сценарий объединения потоков

 const stream1=observable
    .pipe(tap(() => dosmg()))

const stream1WithLoggin=stream1.pipe(tap(message=>console.log(message))
const stream1WithHttp=stream1.pipe(mergeMap(message=>fetch(someurl))

1. «Если вы добавляете логику в subscribe, это просто теряет переносимость» Почему?

2. То, что возвращается из subscribe, — это подписка, которая больше не может быть продлена или передана по каналу для дальнейшего использования

3. Это не объясняет _»потерю переносимости»_.

4. Тогда зачем вам нужен operator, если вы хотите поместить логику в subscribe? оператор предназначен для того, чтобы помочь вам управлять вашей логикой, нет?

5. «должен ли я также показать, почему добавление чего-либо в subscribe() мешает вам в дальнейшем создавать функцию?» Да, потому что подписка на observable не мешает вам создавать на его основе любой другой поток. «точка подписки заключается в выполнении функции» . subscribe создает наблюдателя внутри, даже если вы ничего не передаете. Данные из потока всегда используются наблюдателем. В этом и заключается суть шаблона observer.