Question

问题：你会认为悬挂回调是不好的node.js风格甚至危险吗？如果是这样的前提呢？

案例如下所述，假设您需要在快速服务器中调用更新某些数据的数据库。然而，客户并不需要了解结果。在这种情况下，您可以立即返回响应，不等待异步调用完成。由于缺少更好的名称，这将被描述为悬空回调。

为什么这很有趣？：因为大多数情况下的教程和文档都显示了等待的情况，在最坏的情况下教授回调地狱。回想一下你的第一次使用快递，mongodb和护照的经历。

示例：

'use strict'
const assert = require('assert')
const express = require('express')

const app = express()

function longOperation (value, cb) {
  // might fail and: return cb(err) ...here

  setTimeout(() => {
    // after some time invokes the callback
    return cb(null, value)
  }, 4000)
}

app.get('/ping', function (req, res) {
  // do some declartions here
  //
  // do some request processesing here

  // call a long op, such as a DB call here.
  // however the client does not need to be
  // informed about the result of the operation
  longOperation(1, (err, val) => {
    assert(!err)
    assert(val === 1)
    console.log('...fired callback here though')
    return
  })

  console.log('sending response here...')
  return res.send('Hello!')
})

let server = app.listen(3000, function () {
  console.log('Starting test:')
})

Answer 1

是的，这基本上就是所谓的“火灾和忘记”＃34;在其他环境中提供服务，也可能是实现命令查询响应分离的良好设计的第一步。

我不认为这是一个＆＃34;悬空回调＆＃34;，在这种情况下的回复确认收到了请求。这里你最好的选择是确保你的回复包含某种超媒体，让客户稍后获得他们的请求状态，如果他们可以解决的错误是新资源URL的内容告诉他们如何。

在用户注册工作流程的情况下考虑它，用户必须得到管理员的批准，或者必须在访问之前确认他们的电子邮件。

悬空回调：在每次回调返回之前返回响应

1 个答案: