спасибо за альтернативный вариант. да, можно было бы :) это уже на усмотрение разработчика. да и нативная поддержка этого метода в браузерах еще хуже, чем у самих промисов.
в чем-то Вы правы.
только кому-то достаточно прочитать документацию, кому-то ее может не хватить, возможно, из-за отсутствия тех примеров, которые будут понятны. статьи же пишут с целью поделиться опытом, который другим может помочь лучше разобраться в той или иной теме. иначе, можно всегда ссылаться на документацию, и не только по этой теме, а вообще.
мне кажется, что у Вас как раз задача, решение которой заключается в обработке событий…
если я все правильно понял, то предположу, что задача похожа на «загрузить файл на сервер с возможностью отменить загрузку пока идет процесс»… Если предположение с аналогией верно, то такую задачу (правда на NodeJS), решал именно с помощью обработки событий.
Chrome с версии 32, Firefox с 29-ой, Opera с 19-ой, Safari с 7.1, IE который Edge.
Поэтому стоит использовать полифилы…
novrm рекомендует bluebird. Я, в свою очередь, тоже ей пользуюсь, в том числе и при написании серверного JS (NodeJS). Достаточно много полезных методов реализовано.
раз вызвали resolve или reject(), и «состояние промиса установлено», можно ошибочно предположить, что код, который следует после них, не будет выполнен. Но это не так. Пример:
пример с return resolve или reject().
function myPromise1()
{
return new Promise(function (resolve, reject)
{
var err = true;
if (err)
reject('Promise rejected');
console.log('у нас же "ошибка", почему оказались здесь?');
resolve('Promise resolved');
});
}
myPromise1()
.then(function (res)
{
console.log(res);
})
.catch(function(err){
console.log(err);
});
отчасти, и по этому тоже советовал всегда возвращать return resolve() или reject(), так как по логике, после вызовов этих методов, следующий за ними код не должен вызываться. иначе можно запутать самого себя, разбираясь в чем же дело…
PS. да, есть исключение для этого совета: если эти методы вызываются в качестве колбэков. как правильно заметил Apathetic
Начав писать ответ на вопрос, понял, что не акцентировал внимание на том, что после вызовов resolve() или reject() состояние «промиса» уже нельзя изменить. то есть, вот этот код в обоих случаях выведет фразу вида «Promise rejected», несмотря на то, что в первом варианте нет «return»
resolve() или reject()
function myPromiseRejected()
{
return new Promise(function (resolve, reject)
{
var err = 'error';
if (err)
reject('Promise rejected');
resolve('Promise resolved');
});
}
function myPromiseRejected2()
{
return new Promise(function (resolve, reject)
{
var err = 'error';
if (err)
return reject('Promise rejected2');
return resolve('Promise resolved2');
});
}
myPromiseRejected()
.catch(function(err){
console.log(err);
});
myPromiseRejected2()
.catch(function(err){
console.log(err);
});
В будущем это поможет избежать ситуации, когда код будет работать не так, как ожидается.
Этот фраза больше относилась к тем ситуациям, когда забывают возвращать «промис» в своих методах. При этом экспешина не возникает, например:
return Promise
function myPromise1()
{
return new Promise(function (resolve, reject)
{
var err = false;
if (err)
reject('Promise rejected');
resolve('Promise resolved');
});
}
function myPromise2()
{
new Promise(function (resolve, reject)
{
var err = false;
if (err)
return reject('Promise rejected2');
return resolve('Promise resolved2');
});
}
myPromise1()
.then(function (res)
{
console.log(res);
return myPromise2();
})
.then(function (res)
{
//undefined, хотя долнжо показать "Promise resolved". потому что в myPromise2() не вернули промис
console.log(res);
})
.catch(function(err){
console.log(err);
});
А почему им не быть актуальными? ) async await не так давно уж и появились, если на это намек в вопросе :) да и статья не об эволюции асинхронного программирования в целом, а только о ее части :)
только кому-то достаточно прочитать документацию, кому-то ее может не хватить, возможно, из-за отсутствия тех примеров, которые будут понятны. статьи же пишут с целью поделиться опытом, который другим может помочь лучше разобраться в той или иной теме. иначе, можно всегда ссылаться на документацию, и не только по этой теме, а вообще.
если я все правильно понял, то предположу, что задача похожа на «загрузить файл на сервер с возможностью отменить загрузку пока идет процесс»… Если предположение с аналогией верно, то такую задачу (правда на NodeJS), решал именно с помощью обработки событий.
Поэтому стоит использовать полифилы…
novrm рекомендует bluebird. Я, в свою очередь, тоже ей пользуюсь, в том числе и при написании серверного JS (NodeJS). Достаточно много полезных методов реализовано.
совершенно верно :) именно это я и показал в примере
отчасти, и по этому тоже советовал всегда возвращать return resolve() или reject(), так как по логике, после вызовов этих методов, следующий за ними код не должен вызываться. иначе можно запутать самого себя, разбираясь в чем же дело…
PS. да, есть исключение для этого совета: если эти методы вызываются в качестве колбэков. как правильно заметил Apathetic
Этот фраза больше относилась к тем ситуациям, когда забывают возвращать «промис» в своих методах. При этом экспешина не возникает, например:
о каких настройках приложения вы говорите? не встречал проблем с этим
от чего же не можете?
в доках все написано
app.locals
res.locals
может просто надо поставить cookieParser!?
и вынесите ее в отдельный middleware
пример:
где файл authcheck.js с вашей проверкой…