Comments 16
Изъян этого подхода таков: нужно быть очень и очень внимательным, чтобы не поименовать что-либо во внутренних функциях так же, как и переменные «из кэша», которые вы собираетесь использовать в вашем замыкании. Даже если вам хватит сноровки, чтобы избежать затенения, ссылаться на переменную так высоко в замыкании все равно кажется довольно опасным, и от этого определенно нехорошо.
«Изъян» решается элементарным линтингом, и хорошо бы еще TypeScript сверху.
+5
Что насчет реактивности, observables, RxJS?
0
UFO just landed and posted this here
Кто-нибудь нашёл применение генераторам в своей практике? По мне так они всегда выглядят запутанно и я лучше напишу что то другое.
+1
В Javascript нет синхронного ввода/вывода (далее — I/O) и вообще не поддерживаются блокировки.
В Javascript вообще нет ввода/вывода. Если имеется ввиду nodejs, то там есть функции реализующие блокирующий синхронный ввод/вывод
0
Код можно немного причесать, налегая на замыкания
Часто вижу, как из кода на промисах получают тот же 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
+1
Полностью поддерживаю. Решил бы примерно также.
Есть стойкое ощущение, что многие кто жаждет async/await, просто не до конца понимают как работают промисы, либо не умеют их читать. Потому что async/await, не более чем синтаксический сахар, который лишь улучшает читабельность, делая ваш асинхронный код «smells like» синхронный код.
Есть стойкое ощущение, что многие кто жаждет async/await, просто не до конца понимают как работают промисы, либо не умеют их читать. Потому что async/await, не более чем синтаксический сахар, который лишь улучшает читабельность, делая ваш асинхронный код «smells like» синхронный код.
0
Не из-за таких ли безумных матрешек мы, не в последнюю очередь, стремились вырваться из ада обратных вызовов?
Если javascript разработчик захочет, он всегда найдет способ попасть в ад… Причем не только в ада обратных вызовов. Найдется за что. ;)
А вообще, в статье как-то промисы вообще не раскрыты и, возникает ощущение, что мысль автора, мол это почти тоже самое что и коллбеки. А ведь есть одно, весьма существенное отличие — промисы, если можно так выразиться, stateful, а отличии от коллбеков, которые stateless. Другими словами, промис имеет определенный работ состояний, инкапсулирует в себя результат операции, может быть сохранен в переменную, передан в функцию и был разрезолвен в любом месте в любое время.
Это прям существенные отличия ведь.
0
Sign up to leave a comment.
Разъяснительная беседа об асинхронном программировании в Javascript