В таком случае мы можем сделать монтирование саг динамическим с помощью эффектов fork и cancel. Поэтому можно перенести инициализацию сокета в фабричный метод по созданию канала (`createFreshJobsChannel`). Там уже по обстоятельствам — нам может понадобиться сокет как синглтон с ленивой инициализацией, либо уничтожение сокета при уничтожении канала.
Google Places Autocomplete
Вы правы. В таком случае я бы добавил какой-нибудь параметр в action и обернул в условие delay. Можно логику debounce написать в UI, я бы воспользовался HOC или новыми хуками для переиспользования кода. takeLatest оставить всё равно нужно.
Dropdowns Closer
Хотелось что бы это было частью UI. Только не могу придумать как эффективно и в переиспользуемой манере уведомлять все выпадающие списки о том, что им нужно закрыться. Без отдельной подписки на события window от каждого списка. Может у вас есть какой-нибудь способ на примете?
Спасибо. Думал об этом при написании. В итоге решил оставить как есть для единообразия примеров с delay и delayAndReject. Так как такой код отработает как надо:
И такое поведение является желаемым в большинстве случаев. У библиотеки нет причин полагать, что вызвав cancel на потребителе вы хотите полностью отменить операцию для всех потребителей. Она делает умнее, отслеживая количество активных потребителей и если их больше нет — распространяет отмену вверх по цепочке.
Важно, что каждый вызов then или catch возвращает новый промис связанный с исходным. Поэтому consumerA не равен consumerB и не равен source. И поэтому увидим timer fired и A:
Насчёт fetch. Это не отмена промиса, а отмена нижележащей операции, в данном случае, сетевого запроса. Поэтому промис перейдёт в состояние rejected. Как вы правильно заметили, отмена bluebird-промиса не вызывает ни then, ни catch, что и является желательным поведением при отмене. Пользуясь этой фичей вы вообще не хотите ничего знать о том, как завершиться операция. Отмена через bluebird позволяет отменять именно промисы, а также нижележащие операции, если они такое поддерживают (таймеры, i/o с потоками и т.д.).
Это никак не принижает, а только дополняет, нововведения в fetch, если вы всё таки осмелитесь взять bluebird на клиента. Если нужно чтобы потребители получили уведомление о том, что промис уже ждать не надо, то это другой паттерн — либо timeout либо race.
2) Все таки `Promise.race` отличается и поэтому имеет другое применение. Он ведь перейдет в состояние rejected как только любой из переданных промисов перейдет в rejected. Поэтому наиболее частое применение `Promise.race` это конкурирование запроса с каким-либо событием, например, с таймаутом. С другой стороны, если у нас есть несколько источников информации и мы хотим дождаться ответа от любого из них и не получать ошибку до тех пор пока все источники не вернут ошибку, то будем использовать `Promise.any`. Надеюсь не запутал :)
6) С bluebird мы можем любой промис сделать отменяемым + если операция позволяет, отменить и ее
P.S. Использую bluebird в основном из-за map, any и скорости
Спасибо за комментарий. Предполагается, что потребителям возвращается результат `Promise.try`. Почему-то был уверен, что синхронная ошибка не будет отклонена в коде приведенном вами. Тогда в этом методе и правда нет смысла, поменял текст статьи. Ещё раз спасибо!
Говориться непосредственно об информации, а не о факте доступа к информации.
Операторы связи обязаны хранить на территории Российской Федерации (...) текстовые сообщения пользователей услугами связи, голосовую информацию, изображения, звуки, видео-, иные сообщения пользователей услугами связи — до шести месяцев с момента окончания их приема, передачи, доставки и (или) обработки. Порядок, сроки и объем хранения указанной в настоящем подпункте информации устанавливаются Правительством Российской Федерации.
Насколько я понимаю из текста закона, необходимо будет хранить весь траффик (не уверен что вы имели в виду под логами интернета). За неполных два дня роутер показывает 7 Гбайт трафика. Это просто серфинг в интернете, просмотр видео и т.д., то есть обычные будни.
В таком случае мы можем сделать монтирование саг динамическим с помощью эффектов fork и cancel. Поэтому можно перенести инициализацию сокета в фабричный метод по созданию канала (`createFreshJobsChannel`). Там уже по обстоятельствам — нам может понадобиться сокет как синглтон с ленивой инициализацией, либо уничтожение сокета при уничтожении канала.
Вы правы. В таком случае я бы добавил какой-нибудь параметр в action и обернул в условие delay. Можно логику debounce написать в UI, я бы воспользовался HOC или новыми хуками для переиспользования кода. takeLatest оставить всё равно нужно.
Хотелось что бы это было частью UI. Только не могу придумать как эффективно и в переиспользуемой манере уведомлять все выпадающие списки о том, что им нужно закрыться. Без отдельной подписки на события window от каждого списка. Может у вас есть какой-нибудь способ на примете?
Спасибо. Думал об этом при написании. В итоге решил оставить как есть для единообразия примеров с delay и delayAndReject. Так как такой код отработает как надо:
А такой вызовет
catch
сразу:Давайте разбираться вместе.
Включим отмену:
Для задержки воспользуемся этим методом:
Увидим
timer fired
,A
иB
:Увидим
timer cancelled
:Увидим
timer fired
иB
:Увидим
timer cancelled
:И такое поведение является желаемым в большинстве случаев. У библиотеки нет причин полагать, что вызвав cancel на потребителе вы хотите полностью отменить операцию для всех потребителей. Она делает умнее, отслеживая количество активных потребителей и если их больше нет — распространяет отмену вверх по цепочке.
Важно, что каждый вызов
then
илиcatch
возвращает новый промис связанный с исходным. ПоэтомуconsumerA
не равенconsumerB
и не равенsource
. И поэтому увидимtimer fired
иA
:Насчёт fetch. Это не отмена промиса, а отмена нижележащей операции, в данном случае, сетевого запроса. Поэтому промис перейдёт в состояние rejected. Как вы правильно заметили, отмена bluebird-промиса не вызывает ни then, ни catch, что и является желательным поведением при отмене. Пользуясь этой фичей вы вообще не хотите ничего знать о том, как завершиться операция. Отмена через bluebird позволяет отменять именно промисы, а также нижележащие операции, если они такое поддерживают (таймеры, i/o с потоками и т.д.).
Это никак не принижает, а только дополняет, нововведения в fetch, если вы всё таки осмелитесь взять bluebird на клиента. Если нужно чтобы потребители получили уведомление о том, что промис уже ждать не надо, то это другой паттерн — либо
timeout
либоrace
.2) Все таки `Promise.race` отличается и поэтому имеет другое применение. Он ведь перейдет в состояние rejected как только любой из переданных промисов перейдет в rejected. Поэтому наиболее частое применение `Promise.race` это конкурирование запроса с каким-либо событием, например, с таймаутом. С другой стороны, если у нас есть несколько источников информации и мы хотим дождаться ответа от любого из них и не получать ошибку до тех пор пока все источники не вернут ошибку, то будем использовать `Promise.any`. Надеюсь не запутал :)
6) С bluebird мы можем любой промис сделать отменяемым + если операция позволяет, отменить и ее
P.S. Использую bluebird в основном из-за map, any и скорости
Для авторизации:
POST /api/v1/sessions
Для вступления пользователя в группу:
POST /api/v1/groups/42/members
POST /api/v1/groups/42/moderators