Ispeziona sinceramente una promessa anti-pattern?

Question

Ispeziona sinceramente una promessa anti-pattern?

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

1

Le promesse native di ES6 non ti permettono di verificare in modo sincrono se sono risolte / in attesa / fallite o di estrarne il valore. A volte ho bisogno di questa funzionalità e quindi devo codificarlo manualmente.

Questo è considerato un anti-modello? Questo è il motivo per cui questa funzione è stata lasciata fuori dallo standard?

Questa è una situazione in cui penso che questo tipo di funzionalità sia utile:

// the render method of a React component
// it will get triggered by other events other than the promise state change
render() {
  if (promise.resolved) {
    // render the result
  } else if (promise.rejected) {
    // render an error/reason
  } else {
    // render a loading message
  }
}

anti-patterns javascript promises es6

posta adrianton3 07.02.2016 - 15:06

fonte

3 risposte

Leggi altre domande sui tag anti-patterns javascript promises es6

c # estensione di una classe di entità framework Come funziona il meccanismo di copia e incolla e si tratta di un modello di progettazione standard come in GoF?

score 1 · Answer 1

Il problema principale di cui sono a conoscenza con l'ispezione sincrona è che non è necessario, a meno che il tuo codice non contenga la promessa di risolvere o rifiutare entro un certo numero di tick, che è esattamente il tipo di cosa su cui non devi fare affidamento.

Ad esempio, anche se non so nulla di React, sono abbastanza sicuro che il tuo esempio possa essere modificato in qualcosa del genere:

this.text = "";

var promise = ...;
promise.then(function(result) {
    this.text = "Success: " + JSON.stringify(result);
}).catch(function(error) {
    this.text = "Error: " + JSON.stringify(error);
});

...

render() {
  // render the current value of this.text
}

Si potrebbe anche obiettare che questa versione è meglio disaccoppiata perché ora il metodo render non ha idea che il valore di this.text dipenda da quella specifica promessa. Ora puoi facilmente fare in modo che% co_de dipenda dai risultati di diverse promesse concatenate insieme senza causare un'esplosione combinatoria di controllo sincrono delle istruzioni if

.

L'unico altro argomento per l'ispezione sincrona di cui sono a conoscenza è che " è noto in alcuni percorsi di codice che una promessa è garantita per essere soddisfatta a quel punto - sarebbe quindi estremamente scomodo da utilizzare. Quindi per ottenere il valore della promessa dato che la richiamata viene sempre chiamata in modo asincrono. "Preferirei usare this.text anche in questi casi, perché una promessa non è veramente garantita per essere soddisfatta finché non ci si trova nel suo .then() handler (o .then handler o qualsiasi altra cosa). Supponendo che altrimenti crei solo un modo ovvio per il mio programma di rompere in futuro, non importa quanto ermetico possa essere il mio argomento oggi. Se il gestore chiamato alla spunta successiva è un problema serio, allora sei già in funzione di quante zecche determinate operazioni eseguono o non eseguono per risolvere / rifiutare, che è qualcosa che devi correggere correttamente piuttosto che aggirare.

score 0 · Answer 2

Lo scopo di una promessa o di un futuro è di consentire alla promessa di perseguire calcoli mentre tu vai a fare qualcos'altro ("in un altro thread"). Una volta che hai finito di fare l'altra cosa e tornare alla promessa di interrogarlo per un valore, l'aspettativa è che tu aspetti il valore (avendo completato "facendo l'altra cosa").

Se vuoi agire immediatamente quando una promessa ha completato il suo compito, penso che tu stia meglio se la "promessa" ti avviserà quando sarà completata. Utilizza un evento, in altre parole.

score 0 · Answer 3

Non lo definirei anti-pattern, lo chiamerei semplicemente sciocco (nella maggior parte dei casi).

Si presume che si usi premesse perché si ha a che fare con un lavoro asincrono. Detto questo, dovresti solo assumere che il suo stato sia in sospeso finché non viene indicato diversamente.

E con ciò detto, presumibilmente avrai anche una sezione di codice che tratta gli eventi / callback promessi. Imposterai uno stato predefinito (in sospeso) e ti iscriverai agli eventi di successo e di fallimento. E, se questa è veramente un'attività asincrona, il codice che controlla la promessa in modo sincrono è probabilmente una duplicazione del codice che risponde agli eventi di successo / fallimento. E se è veramente un'attività asincrona, quel codice duplicato e asincrono probabilmente non verrà mai nemmeno eseguito.