Meteor: Verwendung synchroner Bibliotheken - wrapAsync und bindEnvironment
####Was ist Meteor.wrapAsync und Meteor.bindEnvironment?
In Teil 1 haben wir gesehen, wie Meteor asynchronen Code mit Hilfe von Fibern abstrahierte und eine einfache Möglichkeit bot, JS in einem synchronen Stil zu schreiben. In Teil 2 verstehen wir, wie man mit reinen asynchronen Bibliotheken arbeitet.
Mit Fibers können wir eine asynchrone Funktion modifizieren, um synchronen wie Code zu schreiben. Was passiert jedoch, wenn wir die Funktion nicht ändern können, wie im Falle von Bibliotheken von Drittanbietern?
Unter ShareThis verwendet unsere Meteor-Anwendung Amazons S3 als Cache- und Datenspeicherschicht. Aus der Dokumentation von Amazon S3 sieht die JavaScript-Methodensignatur zum Hinzufügen zu einem S3-Bucket wie folgt aus
“`
getObject(params = {}, callback) ⇒ AWS.Request
//This is how the function would look in Meteor server code
S3.putObject({
Eimer: 'sharethis-insights-store',
Schlüssel: Schlüssel,
Körper: Daten
}, function(err, result){
if(Ergebnis){
console.log("Erledigt");
//optionally pass in callback
}
});
“`
Der obige Code wird nicht wie erwartet funktionieren, da der Rückruf auf S3.putObject nicht an die aktuelle Glasfaser gebunden ist.
In diesem Anwendungsfall verwenden wir Meteor.wrapAsync und , um die asynchrone Funktion in die aktuelle Fiber zu wickeln.
###Was macht Meteor.wrapAsync?
Meteor.wrapAsync nimmt die Methode, die Sie ihm als ersten Parameter geben, auf und führt sie in der aktuellen Faser aus.
Es hängt auch einen Callback an ihn an (es nimmt den traditionellen Knoten-Stil der Verwendung eines Callbacks an, d.h. die Methode nimmt einen Callback als letzten Parameter mit zwei Argumenten (Fehler und Ergebnis) an, von denen entweder eines Null ist, abhängig vom Ergebnis des Aufrufs.
Der Callback ist mit Meteor.bindEnvironment verbunden und blockiert den aktuellen Fiber, bis der Callback ausgelöst wird. Sobald der Rückruf ausgelöst wird, gibt er das Ergebnis zurück oder wirft den Fehler.
"Javascript".
function synchronousFunc(){
return Meteor.wrapAsync(asyncFunction)
}
“`
**Wie greifen wir auf das Fehlerobjekt zu, indem wir die von Meteor.wrapAsync ?** zurückgegebenen synchron eingepackten Funktionen verwenden.
Eine Methode ist die Verwendung von Try/Catch-Blöcken, da sie im Fehlerfall von der Sync-Funktion geworfen werden, anstatt als erstes Argument des asynchronen Funktionsrückrufs übergeben zu werden.
”`
Versuch{
var result=synchronousFunc(params);
console.log("Erfolg :",Ergebnis);
}
catch(Fehler){
console.log("Fehler:",Fehler);
}
// which is equivalent to –
asyncFunction(params,function(error,result){
if(error)
console.log("error",error);
sonst
console.log("Ergebnis :",Ergebnis);
});
“`
Dies ist ideal für die Umwandlung von asynchronem Code in synchronen Code, da Sie das Ergebnis der Methode in der nächsten Zeile verwenden können, anstatt einen Callback zu verwenden und/oder tiefere Funktionen zu verschachteln. Es kümmert sich sogar darum, den Callback an den aktuellen Fiber (mit Meteor.bindEnvironment) für Sie zu binden.
Eine letzte Anmerkung, wenn Sie möchten, dass der Rückruf an die asynchrone Bibliotheksfunktion etwas mehr bewirkt (nur weil) Sie die Meteor.bindEnvironment explizit verwenden müssen, oder wenn Sie einen Fehler erhalten, der besagt, dass Meteor-Code immer innerhalb einer Glasfaser laufen muss.
”`
var func = function(cb){
S3.putObject(params, Meteor.bindEnvironment(function(err, data) {
wenn (err){
throw new Meteor.Error("Storage on S3 Failed");
} sonst{
console.log("Erfolgreich gespeicherte Daten auf S3");
cb(null, data);
}
}));
};
return (Meteor.wrapAsync(func))();
“`
Einige wenige Gotchas, die Sie beachten müssen, wenn Sie Meteor.wrapAsync verwenden.
Es ist für die Arbeit mit reinen Async-Funktionen gedacht, die einen Callback mit Fehler und Ergebnis als Argumente erwarten. Außerdem funktionieren sie nur auf der Server-Seite (da Sie Fibers nicht auf der Client-Seite verwenden können).
Serverseitige Methoden wie Meteor.HTTP.call sind auf diese Weise bereits verpackt. Wenn Sie es ohne Rückruf aufrufen, blockiert die Methode, bis die Antwort empfangen wird. Andernfalls kehrt er sofort zurück und führt den Rückruf nach Erhalt der Netzwerkantwort aus.