Warum JS Promises anstelle von IF/ELSE/Ternary verwenden?

Question

Ich lese ein wenig über JS Promises nach, um up-skill zu lesen.

Hier ist meine quandry: Sagen Sie wollen console.log('we done, bruh!')NACH Ihrer Daten kommen.

so mit einem Versprechen, könnte man sagen:

let iWantToLogOut = function() { 

    let data = fetch('https://jsonplaceholder.typicode.com/users') 

    return new Promise((resolve) => { 
     resolve(data) 
    }) 
} 

Und dann Entschlossenheit, die wie versprechen:

iWantToLogOut().then((dataBack) 
=> databack.json()) 
.then((json) => { 
    console.log('We done, bruh! Look: ', json)   
}) 

Also das ist großartig. Sie erhalten Ihre API-Daten zurück und dann wir protokollieren unsere Nachricht.

Aber ist es nicht nur viel einfacher zu gehen:

let data = fetch('https://jsonplaceholder.typicode.com/users'); 
    data ? console.log('we done, bruh!') : null; 

Ich bin wahrscheinlich über Vereinfachung/etwas fehlt (weil ... na ja ... ich geblieben bin), aber ich Ich möchte nur sicherstellen, dass ich Versprechungen verstehe, bevor ich mich auf Async/Await bewege.

Answer 1

Aber ist es nicht nur viel einfacher zu gehen:

let data = fetch('https://jsonplaceholder.typicode.com/users'); 
data ? console.log('we done, bruh!') : null; 

Es wäre, aber es funktioniert nicht. Was fetch zurückgibt, ist ein Versprechen, nicht das Ergebnis der Operation. Sie können das Ergebnis eines asynchronen Prozesses nicht zurückgeben. Mehr: How do I return the response from an asynchronous call?

In der kommenden ES2017 spec, aber haben wir syntaktischen Zucker um Versprechen Verbrauch, die Sie lassen dies schreiben:

let data = await fetch('https://jsonplaceholder.typicode.com/users'); 
// --------^^^^^ 
console.log('we done, bruh!'); 

Hinweis wir brauchen nicht einmal die Bedingung, weil await ein konvertiert Versprechung in eine Ausnahme versprechen.

würde Dieser Code muß in einer async Funktion, zB:

(async function() { 
    let data = await fetch(/*...*/); 
    // use data here 
})(); 

Das JavaScript-Engine in einigen bereits Browsern async/await unterstützen, aber es in der freien Natur zu verwenden, mögen Sie transpile mit Babel oder ähnlichem.

---

Hinweis: Sie haben

gezeigt

so mit einem Versprechen, könnte man sagen:

let iWantToLogOut = function() { 

    let data = fetch('https://jsonplaceholder.typicode.com/users') 

    return new Promise((resolve) => { 
     resolve(data) 
    }) 
} 

Es gibt ein paar Probleme mit diesem Code:

1. Es wird nie t Er verspricht, dass Sie erstellt haben, wenn die fetch fehlschlägt.

2. Sie ruft etwas data die Daten nicht, es ist ein Versprechen von Daten (das ist vor allem Stil, aber es ist irreführend).

3. Es zeigt die Versprechen Schaffung Anti-Muster. Sie haben bereits ein Versprechen (von fetch), keine Notwendigkeit, ein anderes zu erstellen.

iWantToLogOut sollte einfach sein:

let iWantToLogOut = function() { 
    return fetch('https://jsonplaceholder.typicode.com/users'); 
}; 

das ein Versprechen gibt, die mit den Daten gelöst werden, oder natürlich abgelehnt. Was würden Sie dann mit Versprechungsmethoden oder await (innerhalb einer async Funktion) verbrauchen.

Answer 2

Es ist keine Frage von einfach. Normalerweise sollten Netzwerkaufrufe asynchron gehandhabt werden (ich möchte nicht das Anti-Pattern von synchronen AJAX-Aufrufen). An diesem Punkt haben Sie einige Möglichkeiten, es zu handhaben:

1. Rückrufe
2. Promises
3. Observable

In Ihrem Code oben, wenn es synchron ist, sollte die fetch sofort wieder mit dem Versprechen, dass Die Daten werden nur aufgelöst, wenn der Server geantwortet hat. Nur dann können Sie die Daten auf ihren Inhalt überprüfen. Des Weiteren. Weil jede Verheißung erfüllt oder nicht erfüllt werden kann, können Sie in Ihrem Fall einen Handler für jeden verwenden, anstatt das Ternär zu verwenden.

Von der neuesten Spezifikation:

Synchrone XMLHttpRequest außerhalb der Arbeitnehmer ist in den Prozess der von der Web-Plattform entfernt werden, da sie nachteilige Auswirkungen auf die Endbenutzers Erfahrung hat. (Dies ist ein langer Prozess, der viele Jahre in Anspruch nimmt.) Entwickler müssen für das async-Argument nicht false übergeben, wenn das aktuelle globale Objekt ein Window-Objekt ist. Benutzeragenten werden dringend gebeten, vor einer solchen Verwendung in Entwicklertools zu warnen und möglicherweise mit dem Auslösen einer InvalidAccessError-Ausnahme zu experimentieren, wenn diese auftritt.