Привет, подскажите, пожалуйста, как обернуть blockingGet в try cath

Присоединяюсь, нет понимания преимуществ потоков над промизами*

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

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

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

А что если это и есть смысл реактивного программирования. Чтобы не думали особо и позволили думать тем, кому думать положено по выслуге лет.

Просто для меня оно похоже на размышления над вопросом может ли всемогущий бог создать камень который сам же не сможет поднять. А пока вы думаете, мы пойдем заниматься заработками.

Вот простой пример:
Берем компонент, который завязан на роут, у роута есть параметры, которые передаются для получения данных для компонента. Например ID
Берем поток параметров роута, переключаем поток на поток запроса, добавляем обработчик запроса, результирующий поток прокидываем в шаблон и там с помощью асинк-пайпа наслаждаемся результатами

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

получается что мышление должно быть как бы "с конца" - мы изначально создаем поток шаблона, в который переливаем из потока результата, куда из потока запроса, куда из потока роута

нельзя просто взять и добавить обработчик в цепочку, т.к. она фиксирована и требует нового потока куда будут литься результаты прошлого

Только так тоже не выходит...

Промис - это ОДНО значение, поток - это МНОГО значений. Пример: делаем запрос в БД  и получаем в ответ 1000 записей. В случае промиса мы ждем прихода всех записей, отсюда задержка и расход памяти на их хранение. В случае потока мы обрабатываем каждую запись по ее приходу и сразу отсылаем дальше, в UI например.

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

больше всего я боюсь таких вот "парадигм"
в яваскрипте на моей памяти их родилось и умерло уже 10. и каждая снова и снова учит нас забыть всё и научиться мыслить по новому

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

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

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

рынок технологий это вообще не техпроцессы. это про продажу

парадигма не привязанная к проблеме является инфофлудом, а не паттерном

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

асинхронщину навернули сверху (нода), ибо как известно асинхронка это просто закидывание кода в очередь в конец файла.

очередное "всё есть поток" звучит примерно так же как в яваскрипте звучало "всё есть обьект", что громко сломало всем мозги и заставило учить новый язык, а потом всё равно написали тайпскрипт который сказал что обьект - обьекту рознь, и без примитивов никуда не поедем.

принудительно заставить считать любой источник данных подключением только лишь добавляет мороки, т.к. сама идея протокола http ставилась в том что ты запросил и ответ получил, т.к. долбаться с сокетами тысячу раз в день убивало любое желание кодить.

и вот через 15 лет мы снова сделали что нужно долбаться с сокетами тысячу раз в день и радостно хлопаем, ведь наши деды которые писали на очень слабых машинах просто не воспринимали такое бурление совсем. а вот мы потупели достаточно чтобы радостно плясать всему блестящему. вот и прокатило

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

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

пытаясь разложить этот капец на понятные слова:
1. of() / Observable() / pipe() - это всё конструкторы. Они создают новую "функцию", которая начинается фразой "открой источник данных", и замыкает в себе лютую кучу операций

2. метод subscribe() вопреки тому что многим кажется работает как .then() - не совсем. Сабскрайб создает одновременно два обьекта - подключение куда-то и подписку (возвращает только подписку), которая ждет следующую пачку данных. И вот если речь идет о пачке данных которая имеет начало и конец - то после завершения - подключение закрывается, в теории после выхода из функции обьект удалится и память очиститься - и получается что-то вроде then(). До момента пока бекендер не накосячит и не забудет передать заголовок закрывающий соединение. Если забудет - подписчик будет висеть вечно. А выполнив сотню сабскрайбов случайно в цикле - можно ушатать оперативку даже самого мощного компа.

3. pipe() в отличие от привычного на ноде "добавить обработчик" на самом деле создает чертеж того, как будем подключаться к источнику. то бишь на ноде "открыть файл асинхронно" все равно открывает файл. А пайпы к открытому файлу добавляют что делать с каждым чанком по мере чтения.

А тут пайп ничего не открывает, он только пакует, используя паттерн "билдер" указанные источники и способы их опрашивать в один большой чертеж, который потом будет вызван снова и снова. То есть пайп мы вроде написали, вернули откуда-то из логики, но никакой файл не открылся, а куда разместить код подписки - хороший вопрос, ивенты обычно лежат в единой папке, т.к. штука опасная и можно запутать всех коллег. А здесь ивенты начинают быть везде. Каждый запрос требует создать объект, который данные будет получать!

У промиза мы брали полученное, можно было ничего с ним не делать, оно все равно исчезало. А вот подписчик не исчезает никогда, пока ты не закроешь свою программу или не отпишешься. Ведь подписка хранит ссылку на сам поток и пока хоть одна ссылка есть - данные в памяти лежат вечно

Если офигенно надрючиться, то можно извлекать из этого пользу, но количество неочевидных ошибок по сравнению с работой с промизами будет больше на нолик справа.
отличный пример - делаем "сабжект", и чтобы узнать его значение - по привычке пишем subscribe() к нему. только вот сабжект - это бесконечное подключение. стоит пропихнуть туда что-то - и все подписчики обработаются еще раз. то есть операция "взять значение, валиднуть его и запихнуть назад" будет ломать мозги очень многим людям, т.к. взять и подписаться на будущее не одно и то же. а выглядит как будто так.

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

чтобы сделать такое на промизах нужно было реально написать function get() { return Promise.then(get); }

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