汪汪一只貓
2022-05-22 18:05:09
我很難理解以下概念。我正在發送 OSC 消息以查詢 Ableton 中儀器的狀態,因此我正在進行發射器/接收器組合?,F在,事情是我想避免必須保持某種全局狀態并將所有內容都包裝起來。我確實以以下方式與 Ableto 進行交流:sender.emit("/live/device", queryData);receiver.on("/live/device", function(responseData){// process response here...})所以你可以說我不確定我什么時候取回數據,也不能真正根據響應對新查詢進行排序。我想做的就是簡單地query number of instruments on ONE certain channelget number back query parameters of each instrument of that channel based on first queryreceive parameters back但問題是我不知道如何包裝 eventListener 來響應這些查詢,或者更確切地說如何以非阻塞的方式對它們進行排序,但仍然避免出現某種全局狀態。查詢數據并存儲要由 eventListener 解決的 Promise 似乎是一個解決方案,但后來我陷入了如何將它們傳遞回序列的問題上。經過一番研究,似乎這種行為打破了事件監聽器的整個概念,但我想重點是要有一些全局狀態來跟蹤正在發生的事情,對吧?
1 回答

jeck貓
TA貢獻1909條經驗 獲得超7個贊
事件偵聽器告訴您一些來自用戶操作或任何其他中斷的異步操作。根據您所面對的 API,他們可能會重復使用事件偵聽器來進行回復,而不是為發送 API 提供承諾或回調返回。如果服務器有多個客戶端與之交互,它可能希望同時告訴所有客戶端它們的狀態何時發生變化。
如果您確定無法在 send 方法中直接提供回調以回復您的請求,或者請求不會產生在某些時候通過回復解決的承諾,通常有解決方法。
選項1:發送上下文,接收回來
有些 API 允許向 API 發送“上下文”對象或字符串。然后,每當 API 回答此特定問題及其有效負載時,API 就會將此上下文發送給事件偵聽器。這樣,可以檢查其有效負載的上下文部分是否是對請求的回答。然后,您可以編寫自己的小包裝函數以獲得更直接的發送/回復模式。
選項 2:找出結果數據,如果它符合您的要求
如果結果數據有特定的匹配項,例如 JSON 對象上的鍵,則可能會找出請求是什么。
選項 3:使用您身邊的狀態來跟蹤所有內容
在我見過這樣的 API 的大多數情況下,服務器并不關心請求,只有當它被某種請求更改時才發送它們的當前狀態。客戶端需要通過監聽所有事件來復制服務器的狀態,如果它想顯示當前的服務器狀態。
在我遇到此問題的大多數情況下,我都考慮過選項 1 或 2,但最終還是選擇了選項 3:其他客戶端或硬件開關可能會干擾我的客戶端 UI 并更改服務器狀態,而我沒有監聽該更改。這樣我就會丟失使我的 UI 無效的信息,所以無論如何我都需要監聽和復制服務器/機器/硬件的狀態。
添加回答
舉報
0/150
提交
取消