Крутое выступление! С rxjs уже знаком, но было весьма интересно слушать Глеба, нашёл для себя интересные моменты, которые обязательно стану использовать в дальнейшем
21:31 Вот как раз таки тайпинги в Rx + Typescript всегда просто всю душу выворачивают, и на слайде это даже близко не тайпинг "где черт ногу сломит"... Это очень даже красивые тайпинги.
Спасибо за доклад, полностью поддерживаю, вход в rxjs был тяжелый, но сейчас без него сложно. Брал курс по реакту для саморазвития, в итоге то что в rx одним-двумя операторами решается, там растягивается на энное кол-во хуков и других приемов. Это не лучше и не хуже, просто под задачи посложнее, rx уже более удобен. Но порог входа не супер легкий. Думаю тот же ангуляр придет к связке сигналы+rx, потому что 80% обычного функционала можно будет писать на сигналах, так как там правда проще все выглядит, хоть и функционал скудный, но его хватает, а что-то более сложное уже на rx
Глеб, не слушай хейтеров, доклад - заебись! До этого не сталкивался с Rx-oм, но узнал все интересовавшие меня аспекты: зачем оно нужно, когда его юзать, какие плюсы и минусы, как примерно работает под капотом.
Жестикуляция у докладчика такая, что можно без звука смотреть, и так понятно 😂 Кстати прекрасно его понимаю, я тоже не могу на месте стоять, когда что-то рассказываю со сцены.
6:19 а зачем у каждого источника данных проверять условия если их всех можно проверить в кондейке? Данные то вроде как глобальные так что кондейка может простым ифом у себя проверять)
Спасибо докладчику за то, что даже в своём простом примере показал, как неинтуитивно выглядит код с RxJS, который решает довольно банальную задачу + максимальное его использование имхо возможно только в синтетических ситуациях. В остальных же случаях это имхо оверинжиниринг, который будет ОК, если случайно все в команде на зубок знают RxJS Но докладчику огромный респект за понятное объяснение и подробное предостережение о минусах
RxJS достаточно легко понять если представить его как конвейер по обработки информации. Особенно с ним приятно работать когда нужно работать одновременно с несколькими источниками событий или предполагается какая то сложная логика обработки события. Возвращаясь к тому же примеру с полем поиска. Вы просто добавляете пару операторов делаете переключение на запрос данных и дальше выполняете код. Подобная сложная логика на промисах выглядит не очень, особенно, повторюсь, когда ваш код должен исполняться на основании событий от нескольких источников. Или такой кейс. Вам нужно с определенным делеем запрашивать данные с бэка пока не придет нужное значение или не будет израсходован лимит обращений. Особенно круто в angular это проявляется в работе с реактивными формами. Скажем так, я как и Глеб уже не могу думать о работе с событиями не в парадигме RxJS.
Пример с кондиционером не очень, основная часть реализаций Rx для бэкенда. У меня основной вопрос на которой я не получил ответ: зачем всю сложность и асинхронность переносить на клиента?
В общем случае это делать не нужно. Вопрос в том, что есть задачи которые решаются при помощи rxjs проще, но пока вы точно не убедитесь что у вас такая - тащить rxjs смысла нет
@@ВалерийСмирнов-у9ш тащил не я, но работал с rxjs на двух проектах и на них в целом это было "оправдано" тем что не хватило сил и возможностей у бэка, на одном проекте был один бэк на кмм... 8 фронтов. Если бы нормально организовать распределение ответственности на фронте и на бэке... но нет, тащат сложность на клиента.
@@glebkresh причем тут сложность клиента, есть просто Ангуляр который базово завзян на Rx, и там нету никакой сложности о которой ты даже не упомянул > чем всю сложность и асинхронность переносить на клиента? - Потому что фронт в априоре работает с асинхронностю?) > Сейчас бекенд писать базовый проще чем фронт. Впринципе с 2017 где-то Клиент стал быстрее развиваться чем бек)
Ну тут не в этом дело. Сколько вот слушаю таких докладчиков и не могу понять главное. 1. Зачем использовать промисы с последовательностями (пример с движениями мыши) и 2. зачем использовать rxjs для выполнения REST запросов (в ангуляре) промисы созданы были для рест а rxjs для обработки последовательностей (событий или данных) и весь геморой начинается когда вместо простого запроса (который поддерживается на уровне языка и fetch апи) начинают городить какуюто чушь и всем рассказывать как это охуенно. а я смотрю на это и думаю - о еще одна серебрянная пуля
Всё думал, почему я терпеть не могу rxjs. Наверное просто не понимаю его, что-то делаю не так. Посмотрел это видео. Ну что ж. Всё я делаю так, и понимаю правильно. Чрезвычайно избыточный инструмент для 99% задач. И слишком сложный для 1% случаев где он мог бы быть полезным.
Если человек понимает полностью о том что он говорит , можно считать себя хорошим прогером? Я ангуляр разработчик года 2 , и то что он говорит я понимаю полностью
Это конечно здорово, что ведущий попытался объяснить принципы работы rx-а, но я сильно сомневаюсь что за 30 минут спешки, без проработанной терминологии и вдумчивых объяснений, хоть кто-то, не знавший ранее rx, что-то понял. Я ничего не имею против Глеба, очень умный парень, но суть доклада мне не ясна. Люди которые уже хоть как-то знали и использовали rx не получили новой информации, а те кто не знал rx-а, так нормально ничего и не уяснили. Я считал, что цель таких выступлений именно донести что-то новое. Буду рад другим мнениям.
Ну я знаю rxjs и даже применял его в анимациях. Но такие жонглирования не делал с raf, тем более не создавал свои пайпы (не мыслил такими категориями). Мне было интересно послушать
Кондиционер не освежает воздух, а гоняет ваши выхлопы по кругу. Окно надо открывать для вентиляции. А хочешь экономить на свежем воздухе для работяг интеллектуального труда - стыд и позор.
Какой смысл от преимущества "RxJS СИНХРОНЕН", на 27:47 если в примере с of(1) туда класть обычное число вместо промиса? Доклад, конечно, интересный, но смысла принижать классическое асинхронное программирование из-за декларативного синтаксиса RxJS смысла 0. console.log(1); of(Promise.resolve(3)).subscribe((x) => { console.log(x); x.then((val) => console.log(val)); }); console.log(2); Этот пример выдаст точно такой же результат как если бы Мы сделали console.log(1) Promise.resolve(3).then(console.log) console.log(2) Только еще значительно усложняем синтаксис для подобной задачи. Если хочешь чтобы данные прилетали синхронно, когда они появятся -- есть подходы с callback и EventEmitter, последний из которых, вероятно, и используется в ядре RxJS. Ищите каждой задаче свой инструмент -- и будет Вам счастье.
Крутое выступление! С rxjs уже знаком, но было весьма интересно слушать Глеба, нашёл для себя интересные моменты, которые обязательно стану использовать в дальнейшем
Очень познавательно, я несколько раз пересматривал некоторые моменты. Большое спасибо.
Представили лицо оператора который за Глебом туда-сюда вертел камеру
поменял пару подшипников наверно)
Спасибо за доклад! Возможно не слишком детально, но комфортно слушать в рамках первых шагов к пониманию
только в рамках первых шагов это и можно слушать
21:31 Вот как раз таки тайпинги в Rx + Typescript всегда просто всю душу выворачивают, и на слайде это даже близко не тайпинг "где черт ногу сломит"... Это очень даже красивые тайпинги.
Глеб прекрасный оратор, отличный доклад, спасибо! 👍
Суперпонятные презентации у Глеба - класс
Спасибо за доклад, полностью поддерживаю, вход в rxjs был тяжелый, но сейчас без него сложно. Брал курс по реакту для саморазвития, в итоге то что в rx одним-двумя операторами решается, там растягивается на энное кол-во хуков и других приемов. Это не лучше и не хуже, просто под задачи посложнее, rx уже более удобен. Но порог входа не супер легкий. Думаю тот же ангуляр придет к связке сигналы+rx, потому что 80% обычного функционала можно будет писать на сигналах, так как там правда проще все выглядит, хоть и функционал скудный, но его хватает, а что-то более сложное уже на rx
Супер, я в восторге!
Глеб, не слушай хейтеров, доклад - заебись!
До этого не сталкивался с Rx-oм, но узнал все интересовавшие меня аспекты: зачем оно нужно, когда его юзать, какие плюсы и минусы, как примерно работает под капотом.
Спасибо)
доклад обалденный, пойду читать доку
Бегло, но хорошо:) всегда интересно слушать этого докладчика
Жестикуляция у докладчика такая, что можно без звука смотреть, и так понятно 😂 Кстати прекрасно его понимаю, я тоже не могу на месте стоять, когда что-то рассказываю со сцены.
Доклад - 🔥, RxJS - 🔥
6:19 а зачем у каждого источника данных проверять условия если их всех можно проверить в кондейке? Данные то вроде как глобальные так что кондейка может простым ифом у себя проверять)
20:52 золото
Спасибо докладчику за то, что даже в своём простом примере показал, как неинтуитивно выглядит код с RxJS, который решает довольно банальную задачу
+ максимальное его использование имхо возможно только в синтетических ситуациях. В остальных же случаях это имхо оверинжиниринг, который будет ОК, если случайно все в команде на зубок знают RxJS
Но докладчику огромный респект за понятное объяснение и подробное предостережение о минусах
RxJS достаточно легко понять если представить его как конвейер по обработки информации. Особенно с ним приятно работать когда нужно работать одновременно с несколькими источниками событий или предполагается какая то сложная логика обработки события. Возвращаясь к тому же примеру с полем поиска. Вы просто добавляете пару операторов делаете переключение на запрос данных и дальше выполняете код. Подобная сложная логика на промисах выглядит не очень, особенно, повторюсь, когда ваш код должен исполняться на основании событий от нескольких источников. Или такой кейс. Вам нужно с определенным делеем запрашивать данные с бэка пока не придет нужное значение или не будет израсходован лимит обращений. Особенно круто в angular это проявляется в работе с реактивными формами. Скажем так, я как и Глеб уже не могу думать о работе с событиями не в парадигме RxJS.
Пример с кондиционером не очень, основная часть реализаций Rx для бэкенда. У меня основной вопрос на которой я не получил ответ: зачем всю сложность и асинхронность переносить на клиента?
В общем случае это делать не нужно. Вопрос в том, что есть задачи которые решаются при помощи rxjs проще, но пока вы точно не убедитесь что у вас такая - тащить rxjs смысла нет
Ну и кстати, в большом количестве кейсов, где нужна реактивность - подойдёт реактивность на сигналах
@@ВалерийСмирнов-у9ш тащил не я, но работал с rxjs на двух проектах и на них в целом это было "оправдано" тем что не хватило сил и возможностей у бэка, на одном проекте был один бэк на кмм... 8 фронтов. Если бы нормально организовать распределение ответственности на фронте и на бэке... но нет, тащат сложность на клиента.
@@glebkresh причем тут сложность клиента, есть просто Ангуляр который базово завзян на Rx, и там нету никакой сложности о которой ты даже не упомянул
> чем всю сложность и асинхронность переносить на клиента? - Потому что фронт в априоре работает с асинхронностю?)
> Сейчас бекенд писать базовый проще чем фронт.
Впринципе с 2017 где-то Клиент стал быстрее развиваться чем бек)
Ну тут не в этом дело. Сколько вот слушаю таких докладчиков и не могу понять главное. 1. Зачем использовать промисы с последовательностями (пример с движениями мыши) и 2. зачем использовать rxjs для выполнения REST запросов (в ангуляре) промисы созданы были для рест а rxjs для обработки последовательностей (событий или данных) и весь геморой начинается когда вместо простого запроса (который поддерживается на уровне языка и fetch апи) начинают городить какуюто чушь и всем рассказывать как это охуенно. а я смотрю на это и думаю - о еще одна серебрянная пуля
Всё думал, почему я терпеть не могу rxjs. Наверное просто не понимаю его, что-то делаю не так. Посмотрел это видео. Ну что ж. Всё я делаю так, и понимаю правильно. Чрезвычайно избыточный инструмент для 99% задач. И слишком сложный для 1% случаев где он мог бы быть полезным.
Пример отличный с кондиционером
//на коленке
function mousePosition(cb){
const handle = (param) => { cb(param) }
document.body.addEventListener('mousemove', handle )
return () => document.body.removeEventListener('mousemove', handle )
}
const unsubscribe = mousePosition(({x, y}) => { })
Подскажите чем rxJx превосходит данный вариант. Я просто не тыкал rx
27:18 Всё время существовала Венгерская нотация, а тут Финскую придумали :)
Потом Глеб откроет mobx и тогда его жизнь начнется заново
Надеюсь не будет необходимости)))
Спасибо за доклад!
Прочувствовал когда описывал сложность написания кода ua-cam.com/video/Ibq3EPi2cH4/v-deo.html )))
Ого,Охрименко суперстар. Осенью у него учился девтулзам :)привеееет
Если человек понимает полностью о том что он говорит , можно считать себя хорошим прогером? Я ангуляр разработчик года 2 , и то что он говорит я понимаю полностью
Это значит, что ты понимаешь базу rxjs, цель этого доклада рассказать что rx крут для тех кто еще не (нас ангулярщиков мало, кто понимает rx)
Хороший или не хороший прогер это хумэра-хамера, имеет значение только качество твоей работы.
доклад интересный но мельтешащий туда-сюда автор в маленькой картинке отвлекает
Только не тащите rxJs на бэкенд
XState
Это конечно здорово, что ведущий попытался объяснить принципы работы rx-а, но я сильно сомневаюсь что за 30 минут спешки, без проработанной терминологии и вдумчивых объяснений, хоть кто-то, не знавший ранее rx, что-то понял. Я ничего не имею против Глеба, очень умный парень, но суть доклада мне не ясна. Люди которые уже хоть как-то знали и использовали rx не получили новой информации, а те кто не знал rx-а, так нормально ничего и не уяснили. Я считал, что цель таких выступлений именно донести что-то новое. Буду рад другим мнениям.
Ну я знаю rxjs и даже применял его в анимациях. Но такие жонглирования не делал с raf, тем более не создавал свои пайпы (не мыслил такими категориями).
Мне было интересно послушать
А почему они всегда из стороны в сторону ходят по сцене, у них что, энурез?
Когда началось сравнение с реактивностью вью, какая-то лапша началась
ппц 9месяцев на изучение технологии для синьора. Ну камон )
отвечаю, писать на ней сможешь уже через неделю, а чтобы ей искусно жонглировать - да, 9 месяцев)
Мой мир тоже был разделён: никогда больше говно бесполезное это юзать не буду)
хД
Плиз не ходите по сцене во время рассказа. Очень отвлекает . (
Кондиционер не освежает воздух, а гоняет ваши выхлопы по кругу. Окно надо открывать для вентиляции. А хочешь экономить на свежем воздухе для работяг интеллектуального труда - стыд и позор.
Бро, сгоняй в любой приличный отель в жарком регионе типа Турции, у тебя выключается кондей, когда ты открываешь окно
Стыд и позор?)
Это называется - вентилятор
Есть разные кондиционеры. Поэтому, это тебе стыд и позор🤡
@@TheProfessionalGambler молоко черное
А коробку вне улицы по приколу ставят типо, да?
Какой смысл от преимущества "RxJS СИНХРОНЕН", на 27:47 если в примере с of(1) туда класть обычное число вместо промиса?
Доклад, конечно, интересный, но смысла принижать классическое асинхронное программирование из-за декларативного синтаксиса RxJS смысла 0.
console.log(1);
of(Promise.resolve(3)).subscribe((x) => {
console.log(x);
x.then((val) => console.log(val));
});
console.log(2);
Этот пример выдаст точно такой же результат как если бы Мы сделали
console.log(1)
Promise.resolve(3).then(console.log)
console.log(2)
Только еще значительно усложняем синтаксис для подобной задачи. Если хочешь чтобы данные прилетали синхронно, когда они появятся -- есть подходы с callback и EventEmitter, последний из которых, вероятно, и используется в ядре RxJS.
Ищите каждой задаче свой инструмент -- и будет Вам счастье.