Комментарии 16
Жесть, вот это уродский код, просто кровь из глаз.
async/await вам в помощь и традиционный подход к программированию, тогда и будет вам счастье.
async/await относится к другой парадигме. RxJs манипулирует потоками данных, а не однократным выполнением.
В данной статье разобрана библиотека RxJs которая уже по умолчанию используется в Angular. Вся архитектура данного фреймворка завязана на ней! Все начинающие ангулярщики это знают и данная библиотека уже идет по дефолту к изучению с этим фреймворком. Ни кто не запрещает использовать async/await в купе с RxJs но когда вы попадете в реальную компанию то 99% ассинхроности будет реалезовано с помощью данной библиотеке. Ну а об плюсах по сравнению с async/await можете сами найти в паутине!
Тут скорее кто к чему привык и какая задача стоит, мне, например, гораздо удобнее и понятнее RxJs, нежели async/await и промисы, которые в добавок работают как некая неизбежность - они обязательно так или иначе должны выполнится, а с RxJx можно подписаться на поток когда тебе надо, так же отписаться, получать данные из потока не сразу, а с задержкой, объединять данные с нескольких потоков и ещё много чего. Да, с async/await тоже некоторые подобные штуки можно делать, но выглядеть это будет "не очень", плюс достаточно сложно для прочтения это будет.
Тут скорее кто к чему привык и какая задача стоит, мне, например, гораздо удобнее и понятнее RxJs, нежели async/await и промисы
Да, с async/await тоже некоторые подобные штуки можно делать, но выглядеть это будет "не очень", плюс достаточно сложно для прочтения это будет.
А можно пожалуйста пример из реальной жизни, т.е. то, что в реальности приходится решать разработчикам фронта, хотя бы в среднем на каждом пятом проекте где именно код с RxJs будет понятней/лучше, а традиционная разработка с тем же async/await просто не решит задачу или код будет непонятным по сравнению с RxJs? Прям ссылку на codesandbox/stackblitz пришлите, а я реализую то же поведение, но традиционными методами, просто сравним код хотя бы даже ради интереса. А то всё что я всегда слышу это о каких-то магических кейсах и сценариях где Rx это пушка, но реального сценария я так никогда и не видел где он выигрывает традиционный подход. Надеюсь вы такой сценарий предоставите, главный критерий это реальный, а не вымышленный или 1 на 10000 кейс. Буду очень благодарен.
Чтобы дернуть один запрос с бекенда async, await достаточно, как и в 99% задач фронта. Странно говорить про технологию/методологию что она фигня, ничего в ней не понимая. Код на rx точно ни в каком виде не будет понятнее, если никогда не работал с rx.
Это другая парадигму программирования (реактивное программирование) лично у меня он на фронте не прижился, на проектах был не только я, а порог входа там на голову выше чем async/await и я из мира реакта, а не ангуляра, где rx - дефолт.
Но на беке активно его использовал именно для обработки потоков данных. Вообще выучил его с 0 когда мне нужно было приоритезированную очередь сделать. Могу даже код показать
https://github.com/snicksnk/inst-observer/blob/develop/src/utils/ig-queque/request/requesSheduleFactory.ts
Но естественно ты там ничего не поймешь.
Еще rxjs всегда под капотом у nestjs
Отдельная песня это тестирование марбл диаграммами, это вообще другой подход к разработке, когда ты с потоками данных работаешь, а не с императивными функциями, просто с приставкой await
Но на беке активно его использовал именно для обработки потоков данных
Просто абстрактно и опять 0 конкретики, а именно что тут традиционный подход не канает или код будет нечитемым.
Вообще выучил его с 0 когда мне нужно было приоритезированную очередь сделать
И? При чем тут rxjs если это достаточно тривиальная штука. Опять же 0 конкретики, какая-то абстрактная очередь.
Еще rxjs всегда под капотом у nestjs
И что теперь? А если бы там был под капотом jQuery первой версии? Или Redux?
когда ты с потоками данных работаешь, а не с императивными функциями, просто с приставкой await
Опять максимально абстрактные слова без конкретики и кода.
P.S. Очередное подтверждение, что RxJs не может противопоставить традиционному подходу ничего, от слова совсем. Разве только write-only код, от которого кровь из глаз льется
Конечно абстрактно, мы про абстракции и говорим
Во первых rx и async/await сравнивать это бред. Давай хотя бы rx и промисы сравнивать, а не их обертку.
Во вторых: В чем измерять читаемость? Какие единицы измерения? Или если не понимаешь значит по определению плохо?
Пример неста, как очень меинстримового решения и rxjs под капотом это как раз более объективная метрика успешности rx чем читаемость кода конкретно тобой.
Там и промисы с await и rx уживаются по тому что хорошо решают разные задачи.
Ты можешь реализовать (момент про тривиальность улыбнул) асинхронную, конкурентную, приоритизированную очередь использую только Promise.all, .race, .any. И все. А можешь использовать пару десятков уже готовых функций (включая аналоги этих 3х) для работы с потоками данных https://rxmarbles.com/
Я там писал выше что кнопки красить и простой json гонять можно и без rx. Если ты не сталкиваешься с задачами, которые решает rx, это не значит что он плох, я к этому веду
Зато с rxjs можно локаничненько сделать retry для http запросов. Типо какdefer(() =>
this._telegraf.telegram.sendDocument(this._chatID, url, {
caption,
}),
)
.pipe(retry({ count: 3, delay: 5 * 1000 }))
.subscribe({
next: async (value) => {
if (value?.message_id) await this.cache.set(`${MESSAGE_ID_PREFIX}_${value.message_id}`, { text: caption });
},
error: (error) => {
const errMessage = `Error: ${error}. File url: ${url}`;
this.logService.error(errMessage);
this.sendAlert(errMessage);
},
});
А больше плюсов для рядовых задач я пока не нашел))
Зато с rxjs можно локаничненько сделать retry для http запросов. Типо как
Или так) Без rx'ов))
fetchData = async () => {
this.fetching = true;
try {
this.items = await new ApiReq(`GET /api/v1/docs`).withRetries(3, 5000).send();
} catch (e) {
this.error = e.message;
} finally {
this.fetching = false;
}
}А больше плюсов для рядовых задач я пока не нашел))
Так и эта "фича" элементарно реализуется без rx'ов =) 10 минут и готово)
соединение с сокетом и получить два разных потока данных
const getWs = (dataType) => {}
getWs(dataOne).pipe(takeUntil(unSubcribeSubject)).subscribe()
getWs(dataTwo).pipe(takeUntil(unSubcribeSubject)).subscribe()
вот давайте традиционным способом getWs, и чтоб можно было отписаться, мы же не хотим утечек?
соединение с сокетом и получить два разных потока данных
Что конкретно вы тут подразумеваете под потоком данных? Каждое соединение/клиента который приконнектился и шлет данные или все подряд данные которые шлют все клиенты или что?
Вообще звучит как обычный EventEmitter))
const unsibscribeFn1 = wsEvents.on('data', dataOne);
const unsibscribeFn2 = wsEvents.on('data', dataTwo);
Ну и когда надо отписываемся
unsibscribeFn1();
unsibscribeFn2();
вот вы и ответили на вопрос, зачем нужен rxjs. это не промисы, а работа с потоками данных. ТК вы сами в этой абстрактной задачи используете евентимитер. не надо говорить что, что то плохое, если не умеет это готовит и использовать. ТК в вы в своем примере применили все тот же паттерн что используется в Rx. и в вашем примере нет и строчки про промисы)
Спасибо за статью, хороший онборд для начинающих.
RxJs есть одна маленькая проблемка, современные генераторы (function*) делают всё тоже самое но лучше, ну вернее производительнее и точно так же не очевидно, поэтому в нем особо нет смысла
RxJs для самых маленьких