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

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

Практика - практикой. Но вопрос был о затратности. Не затратно, хотя и говно.

Функция getState в генераторе доступна на всякий случай

Саги предполагают что у тебя синхронный генератор и асинхронное всё остальное, но это неудобно Я предлагаю взять асинхронный генератор и делать все запросы нормально, а снаружи yield — только сам стейт и он синхронный

Я согласен, нужно сделать async дефолтным. Для синхронного можно на thunk навесить отдельную мидлварь, или вообще сделать factory для передачи своего обработчика yield-ов

@ZeroBias, когда ты спишь?

ребят а есть чет подобное https://stackblitz.com/edit/react-xahpe3?file=index.html только для сервера ?

https://runkit.com/home https://strapi.io/

> https://strapi.io/ что-то похоже на deployd

Спасите! Как называется библиотека графических компонентов крутая красивая?

material ui, antd?

react-strap

Петька, приборы

эпики это из redux-observable?

эпики это из redux-observable?

Da

А можете объяснить, чем эта хуета лучше, чем обычные промисы?

Я про стримы и обзервабл херню

Кроме того что с ангуляра проще переходить?

А можете объяснить, чем эта хуета лучше, чем обычные промисы?

Отменять можно

Легко и приятно

Кроме того что с ангуляра проще переходить?

Ангуляр же внутри rxjs использует для обзерваблов

?

Отменять, и? Зачем?

Отменять, и? Зачем?

Пользователь зашел на страницу, а потом решил сразу уйти

А промис все равно выполнится

Пользователь зашел на страницу, а потом решил сразу уйти

Проигнорировать просто результат промиса? В основном-то промисы -- это запросы, на сервере то как такое обрабатывать? Один хрен что отменил, что проигнорировал

Проигнорировать просто результат промиса? В основном-то промисы -- это запросы, на сервере то как такое обрабатывать? Один хрен что отменил, что проигнорировал

Ну тип оптимизация и тд

Сервер будет знать что это запрос уже не надо выполнить

Ну тип оптимизация и тд

А в чем оптимизация? Я просто не не вижу, вижу только оверхэд из либы над нативной штукой

Но на самом деле дальше туду листа redux-observable не писал ?

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

Вообще есть же видео, там из нетфликса вроде ребята рассказывают

Что и зачем

А можете объяснить, чем эта хуета лучше, чем обычные промисы?

https://www.youtube.com/watch?v=AslncyG8whg

Ну приходит и пусть, он же все равно по одному где-то приходит, или в онмесседж сокета, или в запросах, при чем тут стримы?

Во

Ок, спс, гляну

Пока не осознал

Отменять, и? Зачем?

У нас есть запрос на график для аналитики, который может 5 - 20 секунд выполняться. Если пользователь будет менять фильтры раз в 5 секунд, не дожидаясь ответа, 2ой ответ может придти раньше 1ого, что будет большой ошибкой

race condition называется

Понятно что как бы есть Map, Set. Но почему в обычный объект по дефолту этого не вставлять, какие подводные камни?

У нас есть запрос на график для аналитики, который может 5 - 20 секунд выполняться. Если пользователь будет менять фильтры раз в 5 секунд, не дожидаясь ответа, 2ой ответ может придти раньше 1ого, что будет большой ошибкой

Я просто нумеровал запросы и выбрасывал неактуальные

Я просто нумеровал запросы и выбрасывал неактуальные

Ну это имхо сложнее и неудобнее

Кстати отмену запросов можно на генераторах сделать

Ну это имхо сложнее и неудобнее

Одна переменная прям там же где промис? Зато мой код не тянет лишней абстракции и любой Джун его прочитает и поймет

И код-то на самом деле короче получается

И главное, кого ни спрошу -- отмена единственное о чем говорят

И главное, кого ни спрошу -- отмена единственное о чем говорят

h y p e

И главное, кого ни спрошу -- отмена единственное о чем говорят

debounce, delay, throttling

debounce, delay, throttling

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

И при чем именно упростили, а не "теперь мы каждого нового Джуна месяц учим в нашем коде ориентироваться"

это не обязательно нужно делать стримами. И если у тебя нет таких задач, то тебе это и не нужно

(нетфликс гляну)

Так я и спрашиваю, пример можно?

Знаю я эти ответы "если у тебя нет задач, тебе не нужно", сам так отвечал, это просто значит, что отвечать влом))

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

Вот мне и интересно, он не осилил, или они правда просто очередная сахар либа ни о чем

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

Ты используешь методы map, filter, reduce?

Ты используешь методы map, filter, reduce?

Да

Это може можно назвать стрим операциями.

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

Ок, поясню, мой вопрос про обзервабл стримы из рх

Чисто зачем нужна лмба если на вид без нее проще?

Верю что есть примеры

Но я их не встречал

Вот думаю мб тут кто встречал

ERROR: S client not available

Ок, поясню, мой вопрос про обзервабл стримы из рх

Асинхронные операции и их отмена.

Вот. Отмена. Я привел пример как это сделать на поромисах чище, короче, и чтобы любой новый сотрудник понял. Где я не прав?

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

А не делать для каждого запроса ERROR секцию в редаксе.

Погоди, эррор секция для каждого запроса нужна, если одновременно запросов много и нужно знать, на какой пришла ошибка. Чем поток ошибок поможет узнать, на какой именно это пришло? И что мне мешает к ответу добавить поля саксесс и эррор месседж, которое заполняется, если саксесс фолс?

Нубский вопрос: где лучше сделать запрос на получение данных, которые нужны всему приложению сразу же? Обновления store редакса не успевают подтягиваться, прежде чем произойдет рендер componentWillReceiveProps тоже не помог.

Нубский вопрос: где лучше сделать запрос на получение данных, которые нужны всему приложению сразу же? Обновления store редакса не успевают подтягиваться, прежде чем произойдет рендер componentWillReceiveProps тоже не помог.

Где угодно. Научи компонент ждать данные.

Нубский вопрос: где лучше сделать запрос на получение данных, которые нужны всему приложению сразу же? Обновления store редакса не успевают подтягиваться, прежде чем произойдет рендер componentWillReceiveProps тоже не помог.

На сервере перед отгрузкой

Нубский вопрос: где лучше сделать запрос на получение данных, которые нужны всему приложению сразу же? Обновления store редакса не успевают подтягиваться, прежде чем произойдет рендер componentWillReceiveProps тоже не помог.

Сделай время инициализации. Прости, плохо прочитал сообщение.

Погоди, эррор секция для каждого запроса нужна, если одновременно запросов много и нужно знать, на какой пришла ошибка. Чем поток ошибок поможет узнать, на какой именно это пришло? И что мне мешает к ответу добавить поля саксесс и эррор месседж, которое заполняется, если саксесс фолс?

Ок, плохой пример. Сейчас придумаю. А можешь сделать реплай на своё сообщение о промисах?

А как же... Индексация...

Погоди, эррор секция для каждого запроса нужна, если одновременно запросов много и нужно знать, на какой пришла ошибка. Чем поток ошибок поможет узнать, на какой именно это пришло? И что мне мешает к ответу добавить поля саксесс и эррор месседж, которое заполняется, если саксесс фолс?

Так?

А как же... Индексация...

Не всё требует индексации.

Сделай время инициализации. Прости, плохо прочитал сообщение.

Как это правильно погуглить?)

Одна переменная прям там же где промис? Зато мой код не тянет лишней абстракции и любой Джун его прочитает и поймет

Так?

Как это правильно погуглить?)

Сделай корневой компонент, который отображает сообщение "Загрузка", пока основные данные не загрузились.

Так?

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

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

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

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

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

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

https://codesandbox.io/s/mqw1pnnzlx Сделал пример компонента на стримах Кнопка растёт при щелчке) Стрим используется не только в самом компоненте, но и jss тоже получает вместо функции стрим

Интересно, посмотрю

Спс

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

Сделай корневой компонент, который отображает сообщение "Загрузка", пока основные данные не загрузились.

Этот запрос происходит только в случае, если пользователь авторизован. Не очень представляю, как сделать корневой компонент для части компонентов, отрисовывающихся в switch роута

Сделай хок ifAuthorized и оберни все нужные компоненты.

Ну вот. А внутри его пусть будет хок, который грузит нужные ванные.

? спасибо

У меня после обсуждения возник другой вопрос. Зачем нужен редакс? Почему его не заменить на стримы?

Зачем вообще бек нужен