Qu'est-ce que "callback hell" et comment et pourquoi RX résout-il?

répondez simplement à la question: Pourriez-vous s'il vous plaît aussi montrer comment RX résout le" problème de callback hell " sur cet exemple simple?

la magie est flatMap . Nous pouvons écrire le code suivant dans Rx pour l'exemple de @hugomg:

def getData() = Observable[X]
getData().flatMap(x -> Observable[Y])
         .flatMap(y -> Observable[Z])
         .map(z -> ...)...

c'est comme si vous écriviez des codes FP synchrones, mais en fait vous pouvez les rendre asynchrones par Scheduler .

Callback hell est tout code où l'utilisation de callbacks de fonction dans le code async devient obscure ou difficile à suivre. En général, lorsqu'il y a plus d'un niveau d'indirection, le code utilisant les callbacks peut devenir plus difficile à suivre, plus difficile à remanier, et plus difficile à tester. Une odeur de code est plusieurs niveaux d'indentation en raison de passer plusieurs couches de fonction littérales.

cela se produit souvent quand le comportement a des dépendances, c.-à-d. quand A doit se produire avant B doit se produire avant C. puis vous obtenez le code comme ceci:

a({
    parameter : someParameter,
    callback : function() {
        b({
             parameter : someOtherParameter,
             callback : function({
                 c(yetAnotherParameter)
        })
    }
});

si vous avez beaucoup de dépendances comportementales dans votre code comme ceci, il peut devenir gênant rapidement. Surtout si elle se ramifie...

a({
    parameter : someParameter,
    callback : function(status) {
        if (status == states.SUCCESS) {
          b(function(status) {
              if (status == states.SUCCESS) {
                 c(function(status){
                     if (status == states.SUCCESS) {
                         // Not an exaggeration. I have seen
                         // code that looks like this regularly.
                     }
                 });
              }
          });
        } elseif (status == states.PENDING {
          ...
        }
    }
});

ça ne va pas. Comment Pouvons-nous faire exécuter du code asynchrone dans un ordre déterminé sans avoir à passer tous ces callbacks?

RX est l'abréviation de "reactive extensions". Je ne L'ai pas utilisé, mais Googling suggère que c'est un cadre basé sur l'événement, ce qui a du sens. Les événements sont un motif courant pour faire exécuter le code dans l'ordre sans créer de couplage fragile . Vous pouvez faire en sorte que C écoute l'événement "bFinished" qui ne se produit qu'après que B est appelé "listening to aFinished". Vous pouvez alors facilement ajouter des étapes supplémentaires ou étendre ce genre de comportement, et peut facilement tester que votre code exécute dans l'ordre en diffusant simplement des événements dans votre cas test.

pour répondre À la question de savoir comment Rx résout rappel de l'enfer :

décrivons d'abord l'enfer du rappel.

Imaginez un cas où nous devions faire http pour obtenir trois ressources - personne, planète et galaxie. Notre objectif est de trouver la galaxie, la personne vit dans. Nous devons d'abord attraper la personne, puis la planète, puis la galaxie. Trois rappels pour trois opérations asynchrones.

getPerson(person => {
   getPlanet(person, (planet) => {
       getGalaxy(planet, (galaxy) => {
           console.log(galaxy);
       });
   });
});

chaque appel est imbriqué. Chaque callback interne dépend de son parent. Cela conduit à la "pyramide de la mort" style de rappel de l'enfer . Le code ressemble à un signe>.

pour résoudre cela dans RxJs vous pourriez faire quelque chose comme cela:

getPerson()
  .map(person => getPlanet(person))
  .map(planet => getGalaxy(planet))
  .mergeAll()
  .subscribe(galaxy => console.log(galaxy));

avec l'opérateur mergeMap alias flatMap vous pourriez le rendre plus succinct:

getPerson()
  .mergeMap(person => getPlanet(person))
  .mergeMap(planet => getGalaxy(planet))
  .subscribe(galaxy => console.log(galaxy));

comme vous pouvez le voir, le code est aplati et contient une chaîne unique d'appels de méthode. Nous n'avons pas de "pyramide de la mort".

donc, l'enfer du rappel est évité.

Dans le cas où vous vous demandez, promesses sont une autre façon d'éviter de rappel de l'enfer, mais les promesses sont désireux , pas paresseux comme observables et (en général) vous ne pouvez pas annuler comme facilement.

utilisez jazz.js https://github.com/Javanile/Jazz.js

il simplifier comme ceci:

    // run sequential task chained
    jj.script([
        // first task
        function(next) {
            // at end of this process 'next' point to second task and run it 
            callAsyncProcess1(next);
        },
      // second task
      function(next) {
        // at end of this process 'next' point to thirt task and run it 
        callAsyncProcess2(next);
      },
      // thirt task
      function(next) {
        // at end of this process 'next' point to (if have) 
        callAsyncProcess3(next);
      },
    ]);