aio350 18 янв 2020 в 16:12

Распространенные ошибки при работе с промисами в JavaScript, о которых должен знать каждый

5 мин

22K

JavaScript*Программирование*Веб-разработка*

Перевод

+11

Комментарии 12

НЛО прилетело и опубликовало эту надпись здесь

Dartess 18 янв 2020 в 21:20

Либо автор оригинальной статьи уже исправил этот момент, либо тут очень вольный перевод. aio350 перепроверьте, пожалуйста :)

aio350 18 янв 2020 в 22:28

спасибо, поправил

faiwer 21 янв 2020 в 01:20

Но это не означает, что выполнение кода, следующего за промисами, начнется сразу же после разрешения одного из них

But that doesn't mean that it will exit the code immediately after that

Вы что-то не то поправили. Речь идёт о том, что само приложение не умрёт до тех пор пока есть хотя бы 1 событие, которого оно ждёт. Достаточно одного повисшего callback-а, чтобы приложение не умерло само. Но вот выполнение кода следующего за промисами начнётся как раз сразу после "разрешения одного из них"

Там автор пишет:

It will wait until all the promises get resolved and only after that, it will release the thread

Не знаю зачем он решил всех запутать словом thread, которое имеет 100500 значений. Но по сути речь идёт о всём контексте в котором запущена js-VM. В случае nodejs это или весь процесс, или worker. В случае браузера это снова или worker или браузерный tab. А сам Promise.prototype.race работает именно так, как от него и ожидают.

adictive_max 22 янв 2020 в 10:00

Речь идёт о том, что само приложение не умрёт до тех пор пока есть хотя бы 1 событие, которого оно ждёт.

Тут скорее особенность не конкретно промисов, а всего рантайма целиком. В нём в принципе нет каких-то системных средств для досрочного прерывания работы функций, они будут только там, где вы сами их напишите. Вручную сбрасывать таймеры, вручную отменять http-запросы (что тоже работает не везде), делать «флаги смерти» и перепроверять их перед каждым действием внутри функции и т.д.

adictive_max 19 янв 2020 в 09:54

new Promise((resolve, reject) => {
  const data = someFunction()
  // ваш код
  resolve()
})
  .then(data => console.log(data))
  .catch(error => console.log(error))

Чтобы ловить дату в then, её не помешало бы для начала передать в resolve.

Использование асинхронной функции внутри промиса

Тут скорее вопрос, а нахрена так изначально делать? Асинхронная функция при вызове так и так возвращает промис, зачем ёе скармливать в конструктор обычного промиса?

aio350 19 янв 2020 в 12:50

с data согласен, исправил. я тоже задавался этим вопросом, когда переводил статью

AlexSpaizNet 19 янв 2020 в 17:13

Ошибка № 4. Не использовать Promise.all()
Если у Вас есть несколько не зависящих друг от друга промисов, Вы можете выполнить их одновременно.

IMHO тут важно новичку обьяснить что значит «не зависящих друг от друга промисов». С потолка беру пример, но сталкивался похожей ситуацией.

Ну вот пришел новичек, видит 2 функции (с):

1. downloadFile(fileURL) — скачивает файлы, долго…
2. findUserById(userId) — находит юзера в базе, сравнительно быстро
3. someFoo(file, userId)

По бизнесу, мне не нужен юзер что бы скачать файл, и юзеру тоже пофиг на файл. Это важно только для someFoo()

Новичек запихивает это все в PromiseAll. И вроде все правильно, две функции не зависят друг от друга. Работает быстрее.

Но, я встречал людей которые не понимают что если зафейлится findUserById(), функция downloadFile() не отменяется… и продолжает работать.

В итоге, когда все хороше — да, быстрее. Но когда случаются ошибки… мемори лик, пустая трата ресурсов.

Попадался код который ну просто везде юзает Promise.all. Понимает ли новичек что все это не бесплатно, и что в конце концов это все равно пойдет в очередь, и не важно на каком уровне? Нода, нетворк… в итоге вся система страдает, вместо того что бы иметь несколько пускай не очень быстрых мест.

Поправьте если я не прав…