我在Node.js中有一个长时间运行的方法，它一直在监听命令行输出，直到用户关闭命令或错误停止。长话短说，这种方法有三个回调：
on_receive：返回从命令行到回调的任何新输出，作为字符串或转换后的json。on_end：当用户终止执行时，我发送此信息。on_error：当命令行提示错误时，我将其发送给用户。它总是意味着命令行执行的结束，因此事后调用on_end（尽管可以在需要之前调用它）。在任何时候调用该命令后，我会保留引发的衍生子项，因此我可以稍后将其删除或限制该数量。
现在，我打算转向承诺（我正在使用Kris Kowal的图书馆，q，但承诺的三条腿并不完全是我的回调（取自他的维基）：
resolve：用已履行的承诺呼吁解决，导致承诺通过履行承诺的履行价值得到履行。reject：因某种原因而拒绝承诺会导致承诺被拒绝。notify：使用值调用notify会导致承诺通知该值的进度。也就是说，任何使用promise或promises派生的onProgress处理程序都将使用进度值调用。将on_error绑定到reject并将on_end绑定到resolve是有意义的（虽然这也可能来自错误），但最重要的命令是跟踪在这种情况下，on_receive实际上并不与“进度”相关，正如维基所述。
我正在做的这个代码是一个供公众使用的节点包，所以我不知道以这种方式使用notify是否会让其他开发人员感到困惑。
答案 0 :(得分：2)
改变承诺方法的含义是个好主意吗？
绝对没有。
诺言的三条腿并不完全是我的回调
他们不需要。大多数承诺甚至没有进步的概念，这就是它在V2中被弃用的原因。您唯一需要记住的事项是：承诺代表结果，它将异步变为可用。
将
on_error绑定到reject并将on_end绑定到resolve是有意义的（尽管这也可能来自错误）
不，不应该从错误中调用on_end。承诺只能表示流程成功（履行）或失败（拒绝）。一个过程不能同时做到这两点。
在这种情况下，最重要的跟踪命令
on_receive实际上与“进度”无关
是。进度是输出信号。您描述on_receive回调的方式，是您的函数的输入，描述了如何处理某些数据。它可能不是懒惰地提供，但对于函数操作来说是必需。在这种情况下，它应该只是（保持）一个参数。