51 votes

JavaScript asynchrone - Rappels vs différé / promesse

Double Possible:
Quelles sont les différences entre Différé, de Promesse et d'Avenir en Javascript?

Dernièrement, j'ai été faire un effort pour améliorer la qualité de mes applications JavaScript.

Un modèle que j'ai adoptée est d'utiliser un "contexte de données" de l'objet à charger les données de mon application (auparavant, je le faisais directement à mon avis les modèles).

L'exemple suivant retourne des données est initialisée sur le client:

var mockData = (function($, undefined) {

    var fruit = [
        "apple",
        "orange",
        "banana",
        "pear"
        ];

    var getFruit = function() {
        return fruit;
    };

    return {
        getFruit: getFruit
    }
})(jQuery);

Dans la plupart des cas, nous allons être de charger des données depuis le serveur de sorte que nous ne pouvons pas retourner une réponse immédiate. Il semble que j'ai deux options pour la façon dont nous traitons dans notre API:

  1. À l'aide d'un rappel
  2. De retour d'une promesse.

Auparavant, j'avais toujours utilisé la fonction de rappel de l'approche:

var getFruit = function(onFruitReady) {
    onFruitReady(fruit);
};

// ...

var FruitModel = function(dataContext, $) {
    return {
        render: function() {
            dataContext.getFruit(function(fruit) {
                // do something with fruit
            });
        }
    };
};

Cependant, je peux voir comment il est possible de créer dans le rappel de l'enfer, particulièrement lors de la construction complexe des applications JavaScript.

Puis je suis tombé sur les Promesses modèle de conception. Au lieu de demander à l'appelant de fournir un rappel, j'ai plutôt le retour d'une "promesse" que l'on peut observer:

var getFruit = function() {
    return $.Deferred().resolve(fruit).promise();
};

// ...
dataContext.getFruit().then(function(fruit) {
    // do something with fruit
});

Je peux voir les avantages évidents de l'utilisation de ce modèle, surtout depuis que j'ai peut - wait sur de multiples différés objets qui pourraient être très utiles lors du chargement des données d'initialisation pour une seule page de l'application.

Cependant, je suis désireux de comprendre les avantages et les inconvénients de chaque modèle avant de commencer à utiliser soit en colère. Je suis aussi intéressé de savoir si c'est la direction d'autres bibliothèques vont dans. Cela semble être le cas avec jQuery.

Voici un lien pour le violon que j'utilise pour les tests.

18voto

Christophe Points 7878

Les promesses reposent également sur des rappels en coulisse, ce qui fait que ce n'est pas vraiment l'un contre l'autre.

L'avantage des rappels réside dans le fait qu'ils sont faciles à implémenter avec du code JavaScript simple (par exemple, dans les appels ajax).

Les promesses nécessitent une couche d'abstraction supplémentaire, ce qui signifie généralement que vous comptez sur une bibliothèque (ce n'est pas un problème dans votre cas car vous utilisez déjà jQuery). Ils sont parfaits lorsque vous gérez plusieurs appels asynchrones en parallèle.

3voto

Max Fellows Points 224

À la lecture de la jQuery docs que @Pointues liées à l', il semble que la différence est que le report de l'API vous permet de spécifier plus d'une fonction à appeler lorsque votre demande est terminée:

Comme de jQuery 1.5, l'erreur (fail), le succès (fait), et complète (toujours, comme de jQuery 1.6) rappel des crochets sont du premier entré, premier sorti géré les files d'attente. Cela signifie que vous pouvez affecter plus d'un rappel pour chaque crochet. Voir Différé méthodes de l'objet, qui sont mis en œuvre en interne pour ces $.ajax() rappel des crochets.

Voir aussi: reporté.alors()

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X