预检清单
- 我已阅读了此项目的 Contributing Guidelines。
- 我同意遵循此项目遵循的 Code of Conduct。
- 我在问题跟踪器中搜索了一个与我想提交的功能请求相匹配的问题，但没有成功。
问题描述
无法像使用 ipcRenderer.invoke() 和 ipcMain.handle() 那样通过承诺从主进程请求数据。
建议的解决方案
webContents.invoke() 和 ipcRenderer.handle() 的方法。
考虑过的替代方案
有一些第三方库可以做到这一点。其中之一是 electron-promise-ipc。但是由于 ipcRenderer.invoke() 是本机(承诺从主进程传递到渲染器),因此在相反的方向上实现相同的功能是有意义的。
3条答案
按热度按时间f1tvaqid1#
在添加
invoke()时，这是一个故意的遗漏，因为渲染器进程不能像主进程那样在特定时间内返回响应。为了主进程到渲染器的通信方向添加一个类似于invoke的API是有意义的，但一个重要的考虑因素是能够设置一个超时时间，如果在此之后没有收到响应，Promise将会被拒绝。(同样，如果目标帧被导航、包含目标帧的进程被终止，或者由于任何其他原因我们被通知任何事件，这意味着永远不会传递响应，那么Promise也应该被拒绝。)31moq8wy2#
是的，这正是我所怀疑的。不过，它仍然具有很好的功能！
k4ymrczo3#
我理解这个理由，但我还是不明白为什么它不应该在那里。难道不是开发者来决定是否有响应并相应地处理功能吗？目前在主线程中编写两个IPC事件来做这件事是没有意义的。