Разъяснительная беседа об асинхронном программировании в Javascript

[serf]

Изъян этого подхода таков: нужно быть очень и очень внимательным, чтобы не поименовать что-либо во внутренних функциях так же, как и переменные «из кэша», которые вы собираетесь использовать в вашем замыкании. Даже если вам хватит сноровки, чтобы избежать затенения, ссылаться на переменную так высоко в замыкании все равно кажется довольно опасным, и от этого определенно нехорошо.

«Изъян» решается элементарным линтингом, и хорошо бы еще TypeScript сверху.

[taliban]

Зря минусуете человека, все правильно говорил. Современные иде может выхватывать теневые имена и подсказывать где потенциальные ошибки. + на сколько я помню, практически все версии линтеров имеют флаг на такого рода ошибки.

[via-site]

Что насчет реактивности, observables, RxJS?

[funca]

Observable это сильно нишевый и местами логически противоречивый API, поэтому уже кучу времени не может выйти из stage1. Попытки подружить push (RxJS) и pull (IxJS) подходы пока выглядят сыро. Есть надежды на Callbags, но у них сообщество не очень большое.

[inoyakaigor]

С async/await писать код становится всяко проще, главное помнить, что функция объявленная как async возвращает промис (личные грабли).

[bro-dev0]

Кто-нибудь нашёл применение генераторам в своей практике? По мне так они всегда выглядят запутанно и я лучше напишу что то другое.

[comerc]

Пошаговое тестирование в redux-saga.

[Sirion]

Недавно обнаружил, что на генераторах приятно писать, скажем, обход дерева.

[gostev12]

В Javascript нет синхронного ввода/вывода (далее — I/O) и вообще не поддерживаются блокировки.

В Javascript вообще нет ввода/вывода. Если имеется ввиду nodejs, то там есть функции реализующие блокирующий синхронный ввод/вывод

[pavelrevers]

Код можно немного причесать, налегая на замыкания

Часто вижу, как из кода на промисах получают тот же callback hell, и видят спасение в async (а там тоже проблем хватает со случайными блокировками)
Приведу свое решение задачи:

const user = fetchJson('/api/user/self');

const interests = user.then(({id}) => fetchJson(`/api/user/interests?userId=${id}`));

const recommendations = interests.then(
  interests => Promise.all(
    interests.map(i => fetchJson(`/api/recommendations?topic=${i}`))
  )
);

Promise.all([user, interests, recommendations])
  .then(
    ([user, interests, recommendations]) => render(user, interests, recommendations)
  )
  .then(() => console.log('We are done!'));

Избавились и от переменный в замыкании и от проблем с затенением. Разбить эту задачу на функции тоже будет просто.

Получилось чуть менее красиво чем с await, но так у нас нет опасности заблокировать параллельные запросы (хотя в примере их и нет), a Promise поддерживается в большем колличестве сред, чем генераторы/await

[PaulMaly]

Полностью поддерживаю. Решил бы примерно также.

Есть стойкое ощущение, что многие кто жаждет async/await, просто не до конца понимают как работают промисы, либо не умеют их читать. Потому что async/await, не более чем синтаксический сахар, который лишь улучшает читабельность, делая ваш асинхронный код «smells like» синхронный код.

[PaulMaly]

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

Если javascript разработчик захочет, он всегда найдет способ попасть в ад… Причем не только в ада обратных вызовов. Найдется за что. ;)

А вообще, в статье как-то промисы вообще не раскрыты и, возникает ощущение, что мысль автора, мол это почти тоже самое что и коллбеки. А ведь есть одно, весьма существенное отличие — промисы, если можно так выразиться, stateful, а отличии от коллбеков, которые stateless. Другими словами, промис имеет определенный работ состояний, инкапсулирует в себя результат операции, может быть сохранен в переменную, передан в функцию и был разрезолвен в любом месте в любое время.

Это прям существенные отличия ведь.