Pull to refresh

Comments 16

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

«Изъян» решается элементарным линтингом, и хорошо бы еще TypeScript сверху.
Зря минусуете человека, все правильно говорил. Современные иде может выхватывать теневые имена и подсказывать где потенциальные ошибки. + на сколько я помню, практически все версии линтеров имеют флаг на такого рода ошибки.
Что насчет реактивности, observables, RxJS?

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

UFO landed and left these words here
С async/await писать код становится всяко проще, главное помнить, что функция объявленная как async возвращает промис (личные грабли).
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
Кто-нибудь нашёл применение генераторам в своей практике? По мне так они всегда выглядят запутанно и я лучше напишу что то другое.

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

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

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

Часто вижу, как из кода на промисах получают тот же 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

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

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


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

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

Это прям существенные отличия ведь.
Only those users with full accounts are able to leave comments. Log in, please.