我很难理解以下概念。
我正在发送 OSC 消息来查询 Ableton 中仪器的状态，因此我有发射器/接收器组合正在进行。现在，问题是我想避免必须保持某种全局状态并将所有内容都围绕于此。 我确实通过以下方式与 Ableto 进行交流:
sender.emit("/live/device", queryData);
receiver.on("/live/device", function(responseData){
// process response here...
})
因此您可以看出，我不太确定何时收到数据，并且无法真正根据响应对新查询进行排序。
我想做的就是简单
query number of instruments on ONE certain channel
get number back
query parameters of each instrument of that channel based on first query
receive parameters back
但问题是我不知道如何包装事件监听器来响应这些查询，或者更确切地说，如何以非阻塞的方式对它们进行排序，但仍然避免发生某种全局状态。
查询数据并存储由 eventListener 解析的 Promise 似乎是一个解决方案，但后来我陷入了如何将它们传递回序列的问题上。
经过一些研究，这种行为似乎打破了事件监听器的整个概念，但我认为重点是有一些全局状态来跟踪正在发生的事情，对吧？
最佳答案
事件监听器告诉您来自用户操作或任何其他中断的一些异步操作。根据您面临的 API，他们可能会重复使用事件监听器进行回复，而不是为发送 API 提供 promise 或回调返回。如果服务器有多个客户端与之交互，它可能希望同时告诉所有客户端它们的状态发生变化。
如果您确定无法直接在发送方法中提供回调来回复您的请求，或者请求不会产生在某个时刻通过回复解决的 promise ，通常有解决方法。
选项 1:发送上下文，接收返回
有些 API 允许向 API 发送“上下文”对象或字符串。然后，每当 API 回答此特定问题及其有效负载时，都会将此上下文发送到事件监听器。这样，可以检查其有效负载的上下文部分是否是请求的答案。您可以编写自己的小包装函数来实现更直接的发送/回复模式。
选项 2:计算出结果数据(如果符合您的要求)
如果生成的数据具有特定的匹配内容，例如 JSON 对象上的键，则可能可以找出请求是什么。
选项 3:使用您这边的状态来跟踪一切
在我见过的此类 API 的大多数情况下，服务器不太关心请求，仅在某种请求更改时才发送当前状态。如果客户端想要显示当前服务器状态，则需要通过监听所有事件来复制服务器状态。
在大多数情况下，我遇到此问题时，我都会考虑选项 1 或 2，但最终还是选择了选项 3:其他客户端或硬件交换机可能会干扰我的客户端 UI 并更改服务器状态，而我却没有监听到该更改。这样我就会丢失使我的 UI 无效的信息，因此我无论如何都需要监听和复制服务器/机器/硬件的状态。
关于javascript - 等待发出的消息的响应？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/60737421/