Документацию к rxjs надо изучать, да. Но потом зная набор инструментов ты экономишь кучу времени и строчек кода. И затраты времени на изучение документации окупаются.
Это как с reduce у массива. Сначала пытаешься в голове уложить как это работает. А потом не понимаеш как жил без него.
Предлагаю заценить вот эту демку и посмотреть как работает метод zip например. https://www.youtube.com/watch?v=IXBiUmnd0Pk . У меня был кейс когда он мне был нужен. Оцените за сколько времени вы напишете аналог. Тут нет ничего сверхъестественного и всё осуществимо конечно. Но в rxjs он уже есть, отлажен и оптимизирован. И многое другое.
Попробую описать один кейс, после которого вся наша тогдашняя команда влюбилась в rxjs. Пример кода к сожалению сейчас не найду. Жаль конечно, без него всё не так наглядно.
Есть график с несколькими столбчатыми диаграммами, на котором отображается мониторинг состояния некоторых устройств. По веб-сокету постоянно сыпятся сообщения об актуальном состоянии устройств, на каждое событие график приращивается. Сверху графика есть несколько селектов с параметрами фильтрации - производитель, модель устройства, временной интервал, хорошие/плохие/все события, и ещё фиг знает что, не помню. При изменении значения в селекте делается хттп запрос на сервер для получения стартовых значений для нового графика. Пока ожидаем ответ по хттп, график перестаёт прирастать от событий из ws так как пользователя эти данные вроде уже не интересуют. При этом в угла страницы есть несколько крупных строчек с наиболее важными показателями тех. процесса, значения селектов на которые не влияют. Эти данные получаются из тех же событий ws и они соответственно должны актуализироваться.
Человек (вот кстати не помню, может это был и я :) ) сначала неэстетично лавировал между ифами. А потом чел который у нас уже давно был с rxjs, показал как можно это всё завернуть в несколько потоков и по определенным правилам эти потоки мёрлжить/разводить. Кода получилось меньше раза в 3 и он был наглядный. А мы собрались вокруг монитора как дети вокруг Банифация и радовались глядя на код.
Если повезёт и я найду тот код - приложу его позже.
Как автор правильно написал в одном из комментариев, преимущество использования rxjs особенно наглядно видно при обработке большого количества повторяющихся событий. Для одиночных событий есть промис и огород городить не надо.
Надо понимать, что события могут приходить из разных источников и сыпаться в перемешку. Когда логика приложения предполагает четкую последовательность действий, то от rxjs нет никакого выхлопа. Идеально подходит вариант писать "вертикально" через async/await. Получил запрос от пользователя - проверил авторизацию - сходил в бд за данными - посчитал чего-то - отдал ответ. Async/await и голову забивать не надо. Но представьте, что во время ожидания ответа из бд (уж простите мой бэковый уклон, но мне сейчас так проще) произошло какое-то событие, после которого один из шагов await больше выполнять уже не нужно, один серьезно видоизменяется, а один добавляется новый. Ну фиг знает, изменилась котировка акции ниже порогового значения и теперь на услугу А компания больше не готова предоставлять скидку которую запрашивает пользователь, а продажу товара Б теперь надо заморозить на 4 часа. И таких условий может быть не одно, если после каждого шага проверять условия через if то всё очень скоро превратится в большой комок грязи.
А с rxjs такая логика пишется очень компактно и декларативно. Без конкретных примеров мои слова конечно выглядят голословно( Но это всё равно моя позиция.
Думаю это зависит от интенсивности использования специфичных фич socket.io. Банальный бродкаст думаю не даёт большого оверхеда. А вот комнаты и личные сообщения не реализованы в нативном ws и соответственно дают оверхед. А это уже зависит от бизнес задач а не от неумения готовить.
Совершенно правильный вопрос. При изменении вашего кода обычно сильно некогда/лень/забыл обновлять документацию и она стремительно устаревает. Меня приводит в дикий восторг @nestjs/swagger именно тем, что ты 1 раз пишешь исполняемый код, а актуальная документация (в основном полная) генерится автоматически без всяких стрёмных комментариев. Но нест это несколько другая история
Поправьте меня, если я ошибаюсь, но sha256 так же уже небезопасна.
Отличная статья
Можно, можно :)
Документацию к rxjs надо изучать, да. Но потом зная набор инструментов ты экономишь кучу времени и строчек кода. И затраты времени на изучение документации окупаются.
Это как с reduce у массива. Сначала пытаешься в голове уложить как это работает. А потом не понимаеш как жил без него.
Предлагаю заценить вот эту демку и посмотреть как работает метод zip например. https://www.youtube.com/watch?v=IXBiUmnd0Pk . У меня был кейс когда он мне был нужен. Оцените за сколько времени вы напишете аналог. Тут нет ничего сверхъестественного и всё осуществимо конечно. Но в rxjs он уже есть, отлажен и оптимизирован. И многое другое.
Попробую описать один кейс, после которого вся наша тогдашняя команда влюбилась в rxjs. Пример кода к сожалению сейчас не найду. Жаль конечно, без него всё не так наглядно.
Есть график с несколькими столбчатыми диаграммами, на котором отображается мониторинг состояния некоторых устройств. По веб-сокету постоянно сыпятся сообщения об актуальном состоянии устройств, на каждое событие график приращивается. Сверху графика есть несколько селектов с параметрами фильтрации - производитель, модель устройства, временной интервал, хорошие/плохие/все события, и ещё фиг знает что, не помню. При изменении значения в селекте делается хттп запрос на сервер для получения стартовых значений для нового графика. Пока ожидаем ответ по хттп, график перестаёт прирастать от событий из ws так как пользователя эти данные вроде уже не интересуют. При этом в угла страницы есть несколько крупных строчек с наиболее важными показателями тех. процесса, значения селектов на которые не влияют. Эти данные получаются из тех же событий ws и они соответственно должны актуализироваться.
Человек (вот кстати не помню, может это был и я :) ) сначала неэстетично лавировал между ифами. А потом чел который у нас уже давно был с rxjs, показал как можно это всё завернуть в несколько потоков и по определенным правилам эти потоки мёрлжить/разводить. Кода получилось меньше раза в 3 и он был наглядный. А мы собрались вокруг монитора как дети вокруг Банифация и радовались глядя на код.
Если повезёт и я найду тот код - приложу его позже.
Как автор правильно написал в одном из комментариев, преимущество использования rxjs особенно наглядно видно при обработке большого количества повторяющихся событий. Для одиночных событий есть промис и огород городить не надо.
Надо понимать, что события могут приходить из разных источников и сыпаться в перемешку. Когда логика приложения предполагает четкую последовательность действий, то от rxjs нет никакого выхлопа. Идеально подходит вариант писать "вертикально" через async/await. Получил запрос от пользователя - проверил авторизацию - сходил в бд за данными - посчитал чего-то - отдал ответ. Async/await и голову забивать не надо. Но представьте, что во время ожидания ответа из бд (уж простите мой бэковый уклон, но мне сейчас так проще) произошло какое-то событие, после которого один из шагов await больше выполнять уже не нужно, один серьезно видоизменяется, а один добавляется новый. Ну фиг знает, изменилась котировка акции ниже порогового значения и теперь на услугу А компания больше не готова предоставлять скидку которую запрашивает пользователь, а продажу товара Б теперь надо заморозить на 4 часа. И таких условий может быть не одно, если после каждого шага проверять условия через if то всё очень скоро превратится в большой комок грязи.
А с rxjs такая логика пишется очень компактно и декларативно. Без конкретных примеров мои слова конечно выглядят голословно( Но это всё равно моя позиция.
Я голосую за ngxs
Плюсанул в карму просто прочитав название статьи
Раздражает
Я испытываю странную слабость к дарту. Даже не знаю почему. В работе его не использую.
Разработчики - линейный персонал. Ну да, так и есть, за что извиняться то? (я разработчик)
Весьма интересно
Вот да
Хорошо сказано
Забавный комментарий. Не понимаю зачем минусовать.
Думаю это зависит от интенсивности использования специфичных фич socket.io. Банальный бродкаст думаю не даёт большого оверхеда. А вот комнаты и личные сообщения не реализованы в нативном ws и соответственно дают оверхед. А это уже зависит от бизнес задач а не от неумения готовить.
Вот это огонь :)
Мне сейчас не очень удобно смотреть, я не до конца понял. Это уже готовая фича или пока предложение?
Смешались в кучу кони, люди, мухи и котлеты
Совершенно правильный вопрос. При изменении вашего кода обычно сильно некогда/лень/забыл обновлять документацию и она стремительно устаревает. Меня приводит в дикий восторг @nestjs/swagger именно тем, что ты 1 раз пишешь исполняемый код, а актуальная документация (в основном полная) генерится автоматически без всяких стрёмных комментариев. Но нест это несколько другая история
Спасибо за статью