2012-02-22 3 views
2

je la fonction suivante dans coffeescript:Comment retourner la valeur d'un appel async

newEdge: (fromVertexID, toVertexID) -> 
    edgeID = this.NOID 
    @client.methodCall('ubigraph.new_edge', [fromVertexID, toVertexID], (error, value) -> 
     if(error) 
      console.log('ubigraph.new_edge error: ' + error) 
     edgeID = value 
    ) 
    edgeID 

où @ client.methodCall fait référence à la bibliothèque xmlrpc. Ma question est comment retourner la valeur en tant que edgeID. Est-ce que j'utilise un rappel pour ça?

Si tel est le cas, le rappel devrait ressembler à ceci:?

# callback is passed the following parameters: 
# 1. error - an error, if one occurs 
# 2. edgeID - the value of the returned edge id 
newEdge: (fromVertexID, toVertexID, callback) -> 
    @client.methodCall('ubigraph.new_edge', [fromVertexID, toVertexID], (error, value) -> 
     if(error) 
      console.log('ubigraph.new_edge error: ' + error) 
     edgeID = value 
     callback(error, value) 
    ) 

Répondre

3

Oui, callbacks sont la solution habituelle pour les appels asynchrones, parfois vous avez callbacks appeler callbacks appeler callbacks, callbacks tout le long. Je ferais probablement un peu différemment si:

newEdge: (fromVertexID, toVertexID, on_success = ->, on_error = ->) -> 
    @client.methodCall('ubigraph.new_edge', [fromVertexID, toVertexID], (error, edge_id) -> 
     if(error) 
      console.log('ubigraph.new_edge error: ' + error) 
      on_error(error) 
     else 
      on_success(edge_id) 
    ) 

La principale différence est que le mien a callbacks de succès et d'erreur séparés pour que l'appelant peut gérer ces conditions séparément, callbacks séparées pour différentes conditions est une approche commune afin il devrait être familier à la plupart des gens. J'ai également ajouté des rappels non-op par défaut afin que les callbacks soient facultatifs mais le corps de la méthode principale peut prétendre qu'ils ont toujours été fournis.

Si vous n'aimez pas utiliser quatre arguments, vous pouvez utiliser « nommé » arguments pour les callbacks:

newEdge: (fromVertexID, toVertexID, callbacks = { }) -> 
    @client.methodCall('ubigraph.new_edge', [fromVertexID, toVertexID], (error, edge_id) -> 
     if(error) 
      console.log('ubigraph.new_edge error: ' + error) 
      callbacks.error?(error) 
     else 
      callbacks.success?(edge_id) 
    ) 

Utilisation d'un objet/hachage pour les callbacks vous permet d'utiliser le existential operator au lieu de non-ops pour rendre les callbacks optionnels.


Aaron Dufour notes qu'un seul rappel est le modèle habituel dans Node.js de sorte que votre approche originale serait un meilleur ajustement pour Node.js:

newEdge: (fromVertexID, toVertexID, callback = ->) -> 
    @client.methodCall('ubigraph.new_edge', [fromVertexID, toVertexID], (error, edge_id) -> 
     if(error) 
      console.log('ubigraph.new_edge error: ' + error) 
     callback(error, edge_id) 
    ) 
+0

Même avec un rappel, l'utilisateur du La fonction peut décider quoi faire dans chaque cas, mais fondamentalement, votre réponse: les rappels sont la façon de le faire. était celui que je cherchais. Merci – lowerkey

+0

@lowerkey: Assez vrai, mais les rappels séparés semblent être l'approche habituelle; jQuery utilise au moins des rappels séparés pour les conditions de réussite et d'erreur, de sorte qu'il sera familier à la plupart des gens. J'ai (essayé) pour clarifier ceci. –

+1

La plupart des bibliothèques node.js utilisent un seul callback avec l'erreur comme premier paramètre, ce qui leur permet de se parler assez facilement. Je suggérerais cette manière sur les callbacks séparés. –

Questions connexes