Распечатать результат из карты обещаний
Привет, ребята, у меня есть 2 метода.
checkVenueAvailability(venues) {
var replaced = venues.replace(/\t/g, "");
var venues = replaced.split(',');
var length = venues.length;
Promise.all(venues.map(venue => {
return new Promise((resolve, reject) => {
pool.query("SELECT * FROM peminjaman_venue WHERE nama_venue = ?", venue,
function (err, rows, fields) {
if (err) {
return reject(err);
}
return resolve(rows);
})
})
}))
}
А также
mengajukan_event(req, res) {
helper.checkVenueAvailability(req.body.venue_1)
.then(function (result) {
console.info(result);
}).catch(function (err) {
console.info(err);
})
}
Я хочу напечатать результат checkVenueAvailability в mengajukan_event. Как этого добиться. Мой код выше просто возвращает ошибку. Спасибо.
![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)
Ответы 1
Вы не возвращение ничего. Просто верните обещание от Promise.all:
return Promise.all(venues.map(venue => {
// ^^^^^^
Также обратите внимание, что сейчас доступны адаптеры БД с API на основе Promise. Или, если вы не можете его использовать, вы можете использовать util.promisify.
const promiseQuery = util.promisify(pool.query);
потом
checkVenueAvailability(venues) {
var replaced = venues.replace(/\t/g, "");
var venues = replaced.split(',');
return Promise.all(venues.map(venue => promiseQuery("SELECT * FROM peminjaman_venue WHERE nama_venue = ?", venue));
}
(Я также удалил var length = venues.length;, так как length ни для чего не использовался.)
Нужно удалить возврат в новом обещании, разрешить, отклонить?
@jordie_f - То, как у вас есть, это нормально, хотя я бы так не поступил. Я бы просто использовал if (err) { reject(err); } else { resolve(rows); }
Что касается меня, я фанат варианта возврата. Он обрабатывает логику ошибок как можно скорее и предотвращает дополнительный уровень отступов для остальной логики и поддерживает синхронизацию с тем, как возникает обычная ошибка. например. Мы не размещаем дополнительный уровень отступа, когда выдаем обычную ошибку.
@Keith - В этом случае reject(); return; будет более подходящим. Возвращаемое значение обратного вызова не используется, и reject не имеет полезного возвращаемого значения, поэтому return reject(); вводит в заблуждение. По отдельности, когда «остальная логика» - это resolve();, я не вижу проблемы. :-) К счастью, обратные вызовы в стиле Node идут по пути птицы Додо, так что ...
Тогда это if (err) { reject(err); return; } .. Слишком много {}, поэтому я все еще поклонник if (err) return reject(err);, даже если возврат не выполняется. Логика решения заключается в том, что у вас часто есть больше кода, который просто разрешается, у вас может быть преобразование и т. д. Так что весь этот код имеет дополнительный уровень отступов, .. Как видите, я не фанат чрезмерного отступа .. :) .. или слишком большого количества {} ,. Но, как вы говорите, в наши дни это не так важно ...
@Keith - Я бы предпочел иметь пару {} (они все равно должны быть там всегда) и return;, чем вводить в заблуждение код.
misleading code Я думаю, если бы мне пришлось нанять программиста, а он не понял бы -> if (err) return reject(err); Я думаю, мне, возможно, пришлось бы попросить его упаковать чемоданы .. :)
@Keith - вводит в заблуждение, знают ли люди игнорировать тот факт, что он говорит, что возвращает что-то, чего нет и не используется, или нет. Нет причин заставлять человека, читающего код, работать больше, чем необходимо (см. Понятие «когнитивная нагрузка»). В любом случае, я уверен, что у нас есть другие дела, которыми мы должны заниматься. :-)
Да, давай вернемся к работе .. Все еще не согласен с тобой. Я согласен с большинством ваших мыслей, только не с этим ... Функции короткого замыкания для меня всегда приводили к меньшему количеству ошибок, это касается не только Javascript, C++, Delphi и т. д. Для меня обработка ошибок выполняется в первой строке кода, вот и все. переходим к остальной логике. И то, как это затрудняет чтение другим, меня сбивает с толку .. :)
@Keith - у меня нет проблем с функциями закорачивания. Я просто предпочитаю, чтобы это не вводило в заблуждение. :-) Я обнаружил, что отсутствие введения в заблуждение всегда приводит к меньшему количеству ошибок, это не только JavaScript, но и C, C#, Java и т. д.
Полностью согласен, старайтесь не вводить в заблуждение код. Но просто не соглашайтесь с тем, что это ... Да, он возвращает бесполезное значение, я это вижу. Во всяком случае, это действительно личный вкус. Мы все могли бы превратиться в Douglas Crockford и установить одно правило, но тогда у нас не было бы EsLint, и тогда мне было бы грустно ..
@Keith :-) Да, я предпочитаю подключаемые правила, с которыми команда может договориться, а не «Передавать сверху».
Вам нужно вернуть
Promise.all