Сага о редаксе: redux-saga, Данила Дедков

Мир бежит вперед, мы наращиваем сложность и уровни абстрацкий, но одновременно встречаемся с новыми вызовами. Redux-saga - это пока еще не популярный инструмент для абстрагирования сайд-эффектов в redux-приложениях. Взглянем на него поближе.
Презентация: drive.google.com/file/d/1OWak...
Данила Дедков, фулстек-разработчик в Intetics

[@ITKAMASUTRA]

Мне понравился доклад, спасибо!

[@Titanidze17]

О. Камасутра :) И почему в уроках о саге не слова :) Слишком часто ее просят :) Спасибо за уроки ;)

[@anatoliitytarenko4926]

А твои где лекции по саге )?

[@oleksiiborovykov6306]

IT-KAMASUTRA А тебе спасибо за мотивацию в пути самурая. Летим!

[@lededit9761]

Когда Saga будет на уроках? Ждем ;)

[@user-ni1hm8np6v]

Мое почтение! )) Нет на ваших курсах saga... Приходится искать самостоятельно.

[@136machiner]

Хорошая лекция. Простая, для первого знакомства. Спасибо!

[@goshana1987]

Отличный доклад. Спасибо вам!

[@rolloleon4125]

Спасибо за доклад)

[@glebandreev2238]

Очень неплохо рассказывает

[@con3719]

нормально изложил для ознакомления подробней все есть в доках

[@no-thinker-1357]

Жудкий доклад: - Докладчик подразумевает, что когда все данные лежат в одном месте -- это всегда хорошо. - А как же данные, которые за пределами компонента никем не используются? А бойлерплейтный код для них? - Докладчик утверждает, что Promise в redux-thunk -- это не очень удобно. - Но дальше говорит, что в redux-saga есть all и race -- это как Promise.all и Promise.race. (Ура!) - Где-то в середине прозвучало, что в сагах код не зависит от последовательности вызова методов. Это как так? - Приведенный в докладе пример тестов -- это жуть! Они зависимые!! - От первого it() зависит второй it(), от которого зависит третий it(). Жесть какая-то. - Что тестируется -- не понятно. Что был вызов того метода вызов которого выполняется в коде? Что я не идиот? - В примере с think автор обращается к API из замыкания и говорит, что это сложно тестировать. - Ну да, а чего вы хотели? Можно API положить в window, или document, тогда станет еще сложнее тестировать. - А можно использовать один из патернов инъекции зависимостей, как принято уже лет 20-30. - Выводы мягко странные: все знают, что декларативный стиль лучше императивного? Мммм... - Я не согласен, значит я вонючка, по мнению докладчика. Имхо, каждому стилю свое применение! - Архитектурные преимущества -- это по мнению автора то, что саги содержат логику, а акшены -- только экшены. - Дак и в redux-thunk все то же: логика в "санках", а акшены -- это экшены. - Вывод автора, что saga -- это очень удобный и простой инструмент. - И ни слова про жудкую нечитабельность кода на сагах. put, call итп, вместо понятных названий методов. - Ни слова про кучу бойлерплейта для локальных состояний, которые теперь переносятся в store. - Иначе, если у вас не все в store, то все "преимущества" использования rerux-saga теряются. - Удивляет 380 лайков под видео и всего 30 дислайков. Ребята и девушки, кто поставил дислайк, я хочу вас нанять! ;)

[@Nikitosss91]

можешь посоветовать годные видосы по данной тематике, да и в целом о редаксе?

[@Nikitosss91]

@@no-thinker-1357 ничего не понятно, но очень интересно, спасибо, будем шерстить

[@MrDandeeee]

Большинство сделанных выводов обусловлено вашим и моим пониманием -- это обсуждать не будем. Для меня основное -- возможность писать код, который можно переиспользовать где угодно, и композировать как угодно. Сага, как инструмент дала мне такую возможность, ноль ошибок и непредвиденных ситуаций в реальных приложениях, расширение кода делается очевидно. Абстракции отделены, могу сочетать саги друг с другом и использовать производные в где угодно. Вся асинхронная работа пишется аккуратно в столбик и прекрасно отделяется для тестов. Гораздо позже этого доклада популярность приобрели хуки (custom-hooks), что еще раз показывает разумность применения таких идей, но уже другими инструментами. Буду ли использовать Саги далее? Если есть редакс -- однозначно. Опыт положительный.

[@no-thinker-1357]

@@MrDandeeee Дан, есть смысл обсуждать конкретные вещи. Например такие, которые были перечислены выше. Но вы их проигнорировали. И при чем здесь хуки? Не понятно! (Оставлю в скобках, что хуки придумали для тех, кто не осилил работу со state и ООП. Хотя сами хуки ни чуть не проще state!) И честно говоря не вижу какие такие идеи саг были позаимствованы в хуках? Может быть хуки позволяют откатывать многокомпонентные транзакции? Нет! Хотя сама идея такого отката хорошая. Но хорошая там, где она полезна! Имхо, работа со state понятна и прозрачна. На много понятней, чем хуки. Работа со store через redux-thunk лишена тех недостатков, которые есть в redux-saga. Имхо, в вашем докладе отсутствует честное сравнение redux-thunk и redux-saga. Поэтому я и дополнил его своим комментом. Проблема в том, что опираясь на такие нечестные доклады, другие разрабы набирают стэки из более худших инструментов/библиотек. Затем этот худший выбор трансформируется в требования в вакансиях. Что приводит к тому, что начинающие программеры становятся вынуждены осваивать более худшие инструменты. Потом они выбирают плохие инструменты для своих проектов. И круг замыкается. Дан, вызывает сомнение ваша фраза, что redux-saga дала вам "ноль ошибок и непредвиденных ситуаций в реальных приложениях". Просто будьте честнее и ваши доклады станут на порядок круче. Честно, без сарказма. Удачи в профессиональной деятельности.

[@MrDandeeee]

​@@no-thinker-1357 если вы не увидели "честности" в моем мнении в вопросе "использовать ли redux-saga", то вот оно спустя 2+ года работы с ними. Сага -- дает более продвинутую абстракцию над экшенами как минимум уже за счет встроенных примитивов, а далее, как пользователь может писать свои. Если надо композировать или агрегировать экшены, либо чисто отделиться от эффектов -- помогут.

[@user-tj3dr5se4n]

круто

[@88catbus88]

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

[@mikaelgevorgyan4521]

Ой Господи уж лучше удалят этот редакс с этими остальными и сделают,что нибудь нормальное!

[@mikaelgevorgyan4521]

Говорит,что будет функции выглядеть чистыми=)))!А он сам видел в какой ад превращаются эти функции хуже чем верстать и делать работу на обычном css html js!!!Я как увидел какие коды показывает глаза осинели!Что это за бифштекс и песли прибавить к этой функции ещё много чего с тегами.Это уже будет не просто.=))

[@AndrewDevUA]

Абрамов Даниил, если что)

[@KPACIBO_UA]

Как сделать такую мышку ?(как на слайдах когда он водит)

[@katyamelnyk4321]

6:51 Action или правильно action creator?

[@MrDandeeee]

action creator -- это техническая деталь, фокусироваться на ней нет смысла. Примерно как во фразе "Создать инстанс класса" вы будете еще упоминать о вызове конструктора.

[@pavelalekseev5849]

Action - объект (с type), а action creator - функция, которая возвращает action

[@pelid80]

Есть другая точка зрения - доклад о redux-saga с FrontendConf 2017 kzbin.info/www/bejne/hJWXoaWui5don5I .

[@user-vv6jx8qg4v]

Боже, что за ацтой в документации в 100 раз понятнее и лучше написано

[@danielrosenberg570]

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

[@Flame2201]

speed 1.5

[@MrDandeeee]

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

[@inapik]

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

[@vladvladov4095]

Хааарк тьфу! Нудятина...