На мой взгляд все эти observable в стиле rxjs имеют фундаментальный недостаток - там происходит замыкание переменных к которым нет доступа к извне (кстати с redux-saga то же самое так как там состояние замыкается в генераторах которых нельзя клонировать и сохранить в локалсторадж например).
На первый взгяд кажется удобным когда с этим rxjs демонстрируют пример drag-and-drop когда взяли стрим кликов замапили на mousemove и т.д но потом когда приложение развивается и становится более связанным по фичам оказывается нужно в другой части приложения узнать происходит ли в текущий момент драг.
Без rxjs проблема решается просто - ставим обработчик на mousedown и обновляем переменную isDrag и теперь доступ к этой переменной можно получить в любой другой части приложения.
А с rxjs получается уже нужно как-то связывать эти два стрима вместе потому что состояние было замкнуто в этих стримах. И чем больше будем добавлять фич тем больше нужно будет соединять стримы по всему приложению вместо того чтобы работать с состоянием через переменные

Это не недостаток, это фп

штош

Никто не мешает тебе сделать тоже самое с rx, так сказать поднять состояние)

Выноси в сервис который отвечает за drag-and-drop

а что мешает подписаться на соответствующий стрим и получать эту информацию в нужном месте?

То что он может быть ниже по дереву либо в другой ветке

Это решается упаковкой в пустую функцию наблюдаемого выше по дереву. И распаковкой там где надо. Это не вызывает лишних пересчетов и связывает параллельные ветви вычислений.

Сервисы нужны чтобы обрабатывать состояния а не хранить.

Вы знаете что делать. И как правильно. А теперь я иду спать))

я не про конкретный пример, я про тенденцию. С rxjs у нас нет прямого доступа к состоянию и придется мерджить стрим drag&drop-а c другой фичей которой потребовалось состояние isDrag.
А теперь если подумать про действительно масштабные spa приложения где большое количество фич то каждая новая фича будет иметь тенденцию связываться с другой (заказчик такой - вот хочу здесь показать что-то в зависимости от того и того и того ...)
И получается что мы вынуждены будем постоянно связывать эти стримы вручную вместо того чтобы просто обращаться к переменным в апп-сторе

Ну зачем такие крайности, сервисы могут быть stateful.

Есть две книжки красная и синяя, в обоих написано как делать правильно и почему. Сервисы с состоянием это не правильно.

голубая*

так не бывает

фичи они обычно отдельно друг от друга

и если между ними нужна тесная связь или взаимодействие, то это заранее надо предусматривать

на стадии проектирования архитектуры и моделей

внезапно вдруг и ниоткуда редко такие проблемы возникают

собственно в данном случае конкретном с d&d как мне кажется эта фича должна иметь интерфейс в виде стрима на который можно подписаться извне, для получения ее состояния