Le migliori pratiche per i callback in OOP (JavaScript)?

Naviga le tue risposte
0

Per chiunque usi i callback, come posso avvicinarmi quando il metodo è un setter asincrono?

Ecco un esempio 

class API
{
  constructor()
  {
     this.token = null;
  }
  refreshToken(callback)
  {
    request("http://api.com/token", (token) => {
      this.token = token;
      callback(token);
    });
  }
}

Quale sarebbe il punto di restituzione del token se lo avessi già impostato nella proprietà dell'oggetto?

Mi sento sbalordito quando finisco per fare qualcosa del genere: 

api.refreshToken((token) => {
  //callback is used as a 'wait until token arrives' for proceeding code
  request("http://api.com/data?token=" + token);
});

Ma ho bisogno di esso come proprietà dell'oggetto per poter riutilizzare il token, ad esempio: request("http://api.com/data?token=" + this.token);

Ma ora ho due variabili per la stessa cosa, fornite dalla proprietà di OOP e dal callback. È un problema piuttosto stupido, ma ho bisogno di una guida.

    
posta Vic 21.06.2017 - 13:14
fonte

1 risposta

1

Non c'è niente di sbagliato intrinsecamente con questo. Se fornito un argomento mi sento come getToken è un nome di metodo più appropriato, che potrebbe chiamare refreshToken se richiesto: 

class API {
    constructor() {
        this.token = null;
    }
    getToken(callback) {
        if (this.tokenIsValid()) {
            callback(this.token);
        } else {
            this.refreshToken((token) => {
                this.token = token;
                callback(token);
            });
        }
    }
    tokenIsValid() {
        // ...
    }
    refreshToken(callback) {
        // ...
    }
}

Ora un argomento token ha un senso: 

api.getToken(token => {
    request("http://api.com/data?token=" + token);
});

L'aggiornamento del token è un dettaglio di implementazione che non deve essere divulgato al codice utilizzando la classe. Fornisci al codice esterno un metodo getToken . L'aggiornamento del token non è responsabilità del codice che utilizza la tua classe API . Devono solo ottenere il token e non dovrebbero preoccuparsi se il token è obsoleto e deve essere rinnovato.

Il grande vantaggio qui è che sei libero di rifattorizzare la classe API per cambiare il modo in cui gestisce i token e impedire le modifiche a valle del codice utilizzando la classe API.

Questo sarebbe chiamato Separazione delle preoccupazioni .

    
risposta data 21.06.2017 - 13:42
fonte

Leggi altre domande sui tag

Utilizzo degli schemi per il confinamento dei dati per ciascun cliente (o il filtro rispetto a una tabella clienti)? Il servizio applicativo in DDD dovrebbe fare riferimento a entità non root e oggetti valore all'interno di un aggregato?