Асинхронные вызовы в AngularJS

Eugene Varava PHP/Python Developer 24.11.2015 17:41

Оставлю ссылку тут, чтоб не потерять и просматривать по мере осмысления sauceio.com/...-resource-vs-restangular

Ответить

Поддержать

Aleksey Bober I am not looking for a new position 24.11.2015 17:25

посмотрите в сторону RxJS

Ответить

Поддержать

Dmitriy Iashin Javascript Developer 24.11.2015 15:17

посмотрите в сторону $resource сервиса вместо $http. Он позволяет например такое:
HTML
<span ng-bind="data"></span>
JS
$scope.data = $resource('/api/data').get();

при этом у $scope.data прототипа будут все методы промиса

Ответить

Поддержать

Dmitriy Iashin Javascript Developer 24.11.2015 15:19

потом даже можно будет $scope.data.$save() и post запрос отправился на сервер

Ответить

Поддержать

Dmitriy Iashin

anonymous 24.11.2015 16:16

Хм, цікаво, раніше використовував лише $http.

Здається, що пропонований вами $resource щось типу ORM-методів в PHP, так?

Ответить

Поддержать

Dmitriy Iashin

Taras Murzenkov Java Developer. 24.11.2015 17:24

А как хендлить ошибки при помощи $resources? Есть ли аналог .success/.error callbacks?

Ответить

Поддержать

Dmitriy Iashin

Dmytro Shchurov Frontend/React Developer 24.11.2015 20:04

Resource предполагает, что «ошибки» хендлятся сервером и возвращаются в виде http кодов, которые перехватывают http interceptors, настратваемые в config фазе. Кроме того, любой resource при определении предполагает указание своих перехватчиков

Ответить

Поддержать

Taras Murzenkov

Taras Murzenkov Java Developer. 24.11.2015 21:25

Спасибо за ответ. Естественно, под ошибками я подразумевал server error reponse (группы 4хх и 5хх).

Ответить

Поддержать

Dmytro Shchurov

Dmytro Shchurov Frontend/React Developer 25.11.2015 08:45

Часто вместе с кодом сервер возвращает описание проблемы (в каком-то поле возвращаемых данных). Этого достатчно, чтобы на центральном уровне клиента перехватить и вывести какое-нить toastr уведомление. Нет большой необходимости перехватывать ошибки каждый раз по месту. Только, если от кода зависит воркфлоу, но этого лучше избегать, так как это атипаттерн (лучше если дальнейшие шаги будут определяться дополнительным, но «нормальным» вызовом)

Ответить

Поддержать

Taras Murzenkov

Dmitriy Iashin Javascript Developer 25.11.2015 16:04

при этом у $scope.data прототипа будут все методы промиса

Ответить

Поддержать

Dmytro Shchurov

Dmytro Shchurov Frontend/React Developer 25.11.2015 22:17

Для редких, специфичных случаев. Централизованное решение лучше, чем множество $scope.data.message

Ответить

Поддержать

Dmitriy Iashin

Vyatcheslav Potravnyy Front-End Team Lead в Intersog 24.11.2015 13:35

Что вам мешает по прежнему возвращая промис обрабатывать результат запроса (или даже цепочки запросов) прямо в сервисе? Просто возвращайте свой промис, и сами его контролируйте.

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, но концепция та же

Ответить

Поддержать

Eugene Varava PHP/Python Developer 24.11.2015 14:18

понял, буду разбираться с resolve/reject

Ответить

Поддержать

Vyatcheslav Potravnyy

Ivan Stelmakh ASP.NET developer в SoftServe 24.11.2015 21:57

Посмотрите здесь, очень дохочиво разжевано:
habrahabr.ru/post/221111
PS: надеюсь, ссылки на хабр здесь пока еще не запрещены.

Ответить

Поддержать

Eugene Varava

anonymous 24.11.2015 23:31

то есть, вы предлагаете в сервис, респонсобилити которого закрыть приложение от деталей работы с сервером вбрасывать некий хендлинг ошибок (который обычно повлечет изменения ЮАЙ) ? мягко говоря это както не гуд

Ответить

Поддержать

Vyatcheslav Potravnyy

Vyatcheslav Potravnyy Front-End Team Lead в Intersog 24.11.2015 23:49

Reject всегда вернёт управление назад инициатору — там и меняйте юай. Но раз у топикстартера есть задача предварительно обработать данные, то и ошибки ему тоже вероятно понадобится предварительно обработать. Чтобы передать в контроллер на отрисовку готовыми.
А может и не понадобится, тогда //doSomethingWithError будет nothing

Ответить

Поддержать

anonymous

anonymous 24.11.2015 23:59

Только еще один промис вокруг другого добавит неясности а пользы ноль. И как я понял ТС то у него под обработкой подразумевается как раз некий юай, но може я его не так понял

Ответить

Поддержать

Vyatcheslav Potravnyy

Vyatcheslav Potravnyy Front-End Team Lead в Intersog 25.11.2015 00:09

С моей ТЗ ещё один промис вокруг другого научит новичка их грокать. А если он не грокает базовую их концепцию то цепочки ему писать просто рано — подводные камни (вроде обработки ошибок в цепочке) затянут модуль на день.

И как я понял ТС то у него под обработкой подразумевается как раз некий юай, но може я его не так понял

обнаружил, что при использовании $http логика взаимодействия с API не помещается в сервисе

Ответить

Поддержать

anonymous

anonymous 24.11.2015 23:32

и обертывание в новый промис абсолютно не имеет смысла, учите промисы

Ответить

Поддержать

Vyatcheslav Potravnyy

Vyatcheslav Potravnyy Front-End Team Lead в Intersog 24.11.2015 23:56

Спасибо, я в промисы умею и что такое чейнинг знаю. А вот у ТС с этим похоже трудности есть, и чем более явный код тем ему будет легче понять суть.

Ответить

Поддержать

anonymous

zzhou 25.11.2015 17:53

Почему же у вас тогда в коде resolve(data1) а не return data1?

Ответить

Поддержать

Vyatcheslav Potravnyy

Vyatcheslav Potravnyy Front-End Team Lead в Intersog 25.11.2015 18:52

Потому что return не зарезолвит внешний промис.

Ответить

Поддержать

zzhou

anonymous 25.11.2015 23:46

ммм, на самом деле то что вы предложили с промисами не поможет разобраться, а потому тогда лучше старая, ламповая, добрая колбек функция

Ответить

Поддержать

Vyatcheslav Potravnyy

anonymous 24.11.2015 12:47

предполагается возвращать promise, и в контроллере обрабатывать результат — что, по-моему, неудобно, особенно при потребности создать “обертку” на серию запросов.

Передавайте сервісу scope і вам не прийдеться обробляти дані в контролері.

Ответить

Поддержать

zzhou 25.11.2015 17:54

Ewwww. Вы еще на rootScope в сервисах делайте $watch — и потом говорите что Angular медленый.

Ответить

Поддержать

anonymous

anonymous 25.11.2015 18:10

Бачу ваш скепсис, не бачу ваших аргументів.

Якщо обробка запитів дуже велика, про що говорить автор теми, то чому б її не винести в сервіс? Про яке сповільнення ви кажете, через що воно буде виникати?

Ответить

Поддержать

zzhou

zzhou 25.11.2015 19:05

Зачем scope для обработки данных?

Ответить

Поддержать

anonymous

anonymous 25.11.2015 19:15

Думаю мені не цікаво вести дискусію по AngularJS з людиною, яка не розуміє для чого scope передається в сервіс, при асинхронному запиті.

Ответить

Поддержать

zzhou

zzhou 25.11.2015 19:17

Ок. Действительно, что я могу знать про Angular...

Ответить

Поддержать

anonymous

anonymous 25.11.2015 19:37

Как бы скоупа в сервисах быть не должно, т.к. они должны жить в счатливом неведении что и как их юзает

Ответить

Поддержать

anonymous

anonymous 25.11.2015 19:48

Ну scope, звичайно ж, простіше тримати в контролерах — там не прийдеться навіть робити scope.$apply().

Але якщо при асинхронному запиті є потреба написати багато коду для його обробки, то дотримуючись рекомендації розробників «контролер повинен бути маленьким і читабельним», можна частину коду винести в сервіс.

Хоча можна і не передавати scope в сервіси і при цьому виносити більшу частину коду за межі контролерів, але то вже тонкощі... це теж саме що в PHP поділ коду між контролерами і моделями — не завжди чітко видно що треба залишати в контролерах... особливо при використанні ORM.

Ответить

Поддержать

anonymous

anonymous 25.11.2015 22:23

Если много логики для обработки — читай ремапинг, то в сервисе, но скоуп для этого не нужен, контролер должен получить результат и все, ответ вбросить в скоуп, а дальше вся логика в темплейте. Скоуп остается в контролере

Ответить

Поддержать

anonymous

anonymous 24.11.2015 07:35

юзай ngResource, но как по мне промисы намного удобнее и предсказуемы

Ответить

Поддержать