angularjs - promises - promise angular 6

Cadena Angular $ llamadas http correctamente?

Question

He estado leyendo sobre $ q y promesas desde hace días y parece que lo entiendo ... algo. Tengo la siguiente situación en la práctica:

1. Se realiza una solicitud de $ http y verifica si se puede hacer una llamada posterior.

2. Si la primera llamada falla, devuelva "sin datos", si tiene éxito y dice que se puede hacer una llamada, se hace la segunda llamada, si no, "no hay datos" de nuevo. Si la segunda llamada tiene éxito, devuelve datos, si no, "no hay datos". Se parece a esto (aproximadamente, lo simplifiqué para una idea general, así que no te preocupes por los errores menores aquí):

           return $http.get (something)
               .then(function(allowedAccess){
                   if(allowedAccess){
                       return $http.get (somethingElse)
                           .then( function(result){return {data:result} },
                           function(error){return {data:"n0pe"} }
                       )
                   } else {
                       return {data:"n0pe"}
                   }
               },
               function(){ return {data:"n0pe"} });

Me dijeron que usara $ q aquí. Realmente no entiendo cómo o por qué lo haría. Las llamadas $ http ya son promesas.

Si hay una manera de hacer esto más limpio, no lo veo. Acabo de hacer releer este post sobre el tema . Esencialmente, ¿me estoy perdiendo algo / hay una mejor manera de hacer esto?

Edición: También, solo releer un tutorial sobre promesas de encadenamiento - no maneja en absoluto las fallas de llamadas. Básicamente publicando esto como due diligence.

Edición 2: Esto es más un elaborado sobre la teoría sobre la que estoy preguntando, extracto del primer artículo:

Sin embargo, este es un ejemplo simple. Se vuelve realmente poderoso si tu devolución de llamada then () devuelve otra promesa. En ese caso, el próximo then () solo se ejecutará una vez que se resuelva la promesa. Este patrón se puede usar para solicitudes HTTP en serie, por ejemplo (donde una solicitud depende del resultado de una anterior):

Esto parece estar hablando de cadenas como esta:

   asyncFn1(1)
    .then(function(data){return asyncFn2(data)})
    .then(function(data){return asyncFn3(data)})

Entonces, si entiendo correctamente esto a). No se aplica a mí porque no tengo una tercera función. segundo). Se aplicaría a mí si tuviera tres funciones porque mientras ejecuto una instrucción if dentro de la primera solicitud de $ http, y solo dentro de la declaración if, devuelvo otra promesa. Entonces, teóricamente, si tuviera tres funciones asíncronas para encadenar, ¿necesitaría poner mi declaración if dentro de una promesa?

Answer 1

$ q ayudará a reducir la pirámide de llamadas como esta:

async-call1.then(...
  aysnc-call2.then(...

Esta publicación del blog, http://chariotsolutions.com/blog/post/angularjs-corner-using-promises-q-handle-asynchronous-calls/ , ofrece una forma limpia de realizar múltiples solicitudes HTTP. Note el enfoque más limpio usando $ q. En caso de que estuvieras en un solo punto final HTTP, el uso de tu método hubiera estado bien. Yo diría, lo que tienes está bien también; $ q podría permitir una mayor flexibilidad en el futuro.

La publicación del blog describe un servicio mientras se usa $ qy el código parece más limpio.

service(''asyncService'', function($http, $q) {
  return {
    loadDataFromUrls: function(urls) {
      var deferred = $q.defer();
      var urlCalls = [];
      angular.forEach(urls, function(url) {
        urlCalls.push($http.get(url.url));
      });
      // they may, in fact, all be done, but this
      // executes the callbacks in then, once they are
      // completely finished.
      $q.all(urlCalls)
      .then(...

Soy un principiante con promesas también, así que toma esto con un grano de sal.

Answer 2

Así es como codificaría este tipo de problema:

// returns a promise that resolves some endpoint if allowed
function getDataWithAccess(allowed){
    return allowed ? $http.get(someEndpoint) : $q.reject();
}

// do something with data
function handleData(data){
    // do stuff with your data
}

// main chain
$http.get(accessCredEndpoint)
    .then(getDataWithAccess)
    .then(handleData)
    .catch(function(err){
        return { data: "n0pe" };
    });

Sí, esto se parece mucho a la respuesta de New Dev, sin embargo, quería hacer un punto de extraer las funciones en sus propios bloques. Esto hace que el código general sea mucho más legible.

Answer 3

Las promesas realmente ayudan con la composición del código de hacer llamadas asíncronas. En otras palabras, le permiten redactar su código de una manera similar a la forma en que compondría un conjunto de llamadas síncronas (con el uso de .then encadenados) y como si el código de sincronización estuviera en un bloque try / catch ( con .catch ).

Entonces, imagina que tus llamadas HTTP estaban bloqueando, la lógica que tienes se vería así:

var allowedAccess, data;
try {
  allowedAccess = $http.get(something);

  if (allowedAccess){
    try{
      var result = $http.get(somethingElse);
      data = {data: result};
    } catch (){
      data = {data: "n0pe"};
    }
  } else {
    data = {data: "n0pe"};
  }
} catch (){
  data = {data: "n0pe"};
}
return data;

Podrías simplificarlo un poco:

var allowedAccess, result;
try {
  allowedAccess = $http.get(something);
  var result;
  if (allowedAccess) {
     result = $http.get(somethingElse);
  } else {
     throw;
  }
  data = {data: result};
} catch () {
   data = {data: "n0pe"};
}
return data;

Y eso se traduciría a la versión asíncrona de:

return $http
          .get(something)
          .then(function(allowedAccess){
             if (allowedAccess){
               return $http.get(somethingElse);
             } else {
               return $q.reject(); // this is the "throw;" from above
             }
          })
          .then(function(result){
             return {data: result};
          })
          .catch(function(){
             return {data: "n0pe"};
          })

Al menos, este es el razonamiento que podría aplicar al componer código con sucursales y llamadas asíncronas.

No estoy diciendo que la versión que presenté sea óptima o más corta; sin embargo, está más SECA debido a un solo manejo de errores. Pero tenga en cuenta que cuando lo hace .then(success, error) es equivalente a try / catch en la operación asíncrona anterior, esto puede o no ser necesario dependiendo de su circunstancia específica.