Pull to refresh
21
0
Никита @Accetone

Пользователь

Send message
Звучит действительно хорошо. В скором времени планируем рефакторинг связанного участка кода — обязательно попробую. Спасибо!
Спасибо за вопросы.

WebSockets
В таком случае мы можем сделать монтирование саг динамическим с помощью эффектов fork и cancel. Поэтому можно перенести инициализацию сокета в фабричный метод по созданию канала (`createFreshJobsChannel`). Там уже по обстоятельствам — нам может понадобиться сокет как синглтон с ленивой инициализацией, либо уничтожение сокета при уничтожении канала.

Google Places Autocomplete
Вы правы. В таком случае я бы добавил какой-нибудь параметр в action и обернул в условие delay. Можно логику debounce написать в UI, я бы воспользовался HOC или новыми хуками для переиспользования кода. takeLatest оставить всё равно нужно.

Dropdowns Closer
Хотелось что бы это было частью UI. Только не могу придумать как эффективно и в переиспользуемой манере уведомлять все выпадающие списки о том, что им нужно закрыться. Без отдельной подписки на события window от каждого списка. Может у вас есть какой-нибудь способ на примете?
ошибся тредом

Спасибо. Думал об этом при написании. В итоге решил оставить как есть для единообразия примеров с delay и delayAndReject. Так как такой код отработает как надо:


Promise.resolve(42).delay(1000).then(...);

А такой вызовет catch сразу:


Promise.reject(new Error('boom')).delay(1000).catch(...);

Давайте разбираться вместе.


Включим отмену:


Promise.config({ cancellation: true });

Для задержки воспользуемся этим методом:


function delay(ms) {
  return new Promise((resolve, reject, onCancel) => {
    const timer = setTimeout(() =>  {
       console.log('timer fired');
       resolve();
    }, ms);

    onCancel(() => { 
      console.log('timer cancelled');
      clearTimeout(timer);
    });
  });
}

Увидим timer fired, A и B:


const source = delay(1000);

const consumerA = source.then(() => console.log(`A`));
const consumerB = source.then(() => console.log(`B`));

Увидим timer cancelled:


const source = delay(1000);

const consumerA = source.then(() => console.log(`A`));
const consumerB = source.then(() => console.log(`B`));

source.cancel();

Увидим timer fired и B:


const source = delay(1000);

const consumerA = source.then(() => console.log(`A`));
const consumerB = source.then(() => console.log(`B`));

consumerA.cancel();

Увидим timer cancelled:


const source = delay(1000);

const consumerA = source.then(() => console.log(`A`));
const consumerB = source.then(() => console.log(`B`));

consumerA.cancel();
consumerB.cancel();

И такое поведение является желаемым в большинстве случаев. У библиотеки нет причин полагать, что вызвав cancel на потребителе вы хотите полностью отменить операцию для всех потребителей. Она делает умнее, отслеживая количество активных потребителей и если их больше нет — распространяет отмену вверх по цепочке.


Важно, что каждый вызов then или catch возвращает новый промис связанный с исходным. Поэтому consumerA не равен consumerB и не равен source. И поэтому увидим timer fired и A:


const source = delay(1000);

const consumerA = source.then(() => console.log(`A`));
const consumerB = source.then(() => console.log(`B`));
const consumerС = consumerB.then(() => console.log(`С`));

consumerС.cancel();

Насчёт 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`. Почему-то был уверен, что синхронная ошибка не будет отклонена в коде приведенном вами. Тогда в этом методе и правда нет смысла, поменял текст статьи. Ещё раз спасибо!
Да, будет работать, эти промисы совместимы с нативными
Спасибо, оформление даже лучше получилось чем через gist.
Спасибо, сейчас перенесу код в статью. У вас JS отключен?
Тут есть бенчмарки, может облегчит ваш выбор
Пользуюсь литресом из-за синхронизации текущей позиции в книге десктоп-ноутбук-телефон-планшет. Может знаете приемлемый аналог? Буду благодарен.
А в чем преимущества перед Angular 1.5? По размеру он полегче и вроде большинство перечисленного он умеет. В чем так сказать ваша киллер-фича?
Предыдущие версии ASP.NET MVC, WebAPI и WebPages так же имеют открытые исходники: https://www.asp.net/open-source
Почему не подойдет следующее:

Для авторизации:
POST /api/v1/sessions


Для вступления пользователя в группу:
POST /api/v1/groups/42/members

POST /api/v1/groups/42/moderators


Говориться непосредственно об информации, а не о факте доступа к информации.

Операторы связи обязаны хранить на территории Российской Федерации (...) текстовые сообщения пользователей услугами связи, голосовую информацию, изображения, звуки, видео-, иные сообщения пользователей услугами связи — до шести месяцев с момента окончания их приема, передачи, доставки и (или) обработки. Порядок, сроки и объем хранения указанной в настоящем подпункте информации устанавливаются Правительством Российской Федерации.
Насколько я понимаю из текста закона, необходимо будет хранить весь траффик (не уверен что вы имели в виду под логами интернета). За неполных два дня роутер показывает 7 Гбайт трафика. Это просто серфинг в интернете, просмотр видео и т.д., то есть обычные будни.
насколько я понял, один сегмент весит 500 кг, на схеме 5 сегментов = 2,5 т
Когда починят интеграцию с pocket?

Information

Rating
Does not participate
Location
Минск, Минская обл., Беларусь
Date of birth
Registered
Activity