Потому что return не зарезолвит внешний промис.
С моей ТЗ ещё один промис вокруг другого научит новичка их грокать. А если он не грокает базовую их концепцию то цепочки ему писать просто рано — подводные камни (вроде обработки ошибок в цепочке) затянут модуль на день.
И как я понял ТС то у него под обработкой подразумевается как раз некий юай, но може я его не так понял
обнаружил, что при использовании $http логика взаимодействия с API не помещается в сервисе
Спасибо, я в промисы умею и что такое чейнинг знаю. А вот у ТС с этим похоже трудности есть, и чем более явный код тем ему будет легче понять суть.
Reject всегда вернёт управление назад инициатору — там и меняйте юай. Но раз у топикстартера есть задача предварительно обработать данные, то и ошибки ему тоже вероятно понадобится предварительно обработать. Чтобы передать в контроллер на отрисовку готовыми.
А может и не понадобится, тогда //doSomethingWithError будет nothing
Что вам мешает по прежнему возвращая промис обрабатывать результат запроса (или даже цепочки запросов) прямо в сервисе? Просто возвращайте свой промис, и сами его контролируйте.
angular.module('myModule').factory('myService', ['$http', function($http) {
function fetchOne() {
return new Promise(function(resolve, reject){
$http.get('/server/call').then(
function (data) {
// doSomethingWithData;
resolve(data);
},
function (error) {
// doSomethingWithError;
reject(error);
}
);
})
};
// Several parallel requests
function fetchOne() {
return new Promise(function(resolve, reject){
Promise.all([
$http.get('/server/call/1'),
$http.get('/server/call/2'),
$http.get('/server/call/3'),
$http.get('/server/call/4'),
$http.get('/server/call/5')
]).then(
function (data1, data2, data3, data4, data5) {
// doSomethingWithData;
resolve(data1);
},
function (error) {
// doSomethingWithError;
reject(error);
}
);
})
};
// Public API
return {
fetchOne: fetchOne,
fetchFive: fetchFive
};
}]);
В случае с Ангуляром конечно лучше бы использовать встроенный $q, но концепция та же
Подтверждаю лично