reactjs - 在 React/Redux 应用程序中存储 RTCPeerConnection 对象的最佳位置在哪里？

Question

RTCPeerConnection 是一个具有特定方法的对象，调用时会改变对象(例如，setLocalDescription、addIceCandidate)。这些方法是根据从 WebRTC 连接的另一端接收到的信号来调用的(比如当您收到报价或 ice 候选人时)。

因此，这个对象似乎不太适合放在 redux store 中，因为开发人员一开始并没有控制突变，而且在 redux reducer 中你不能只创建一个副本一个 RTCPeerConnection，因为这会消除您之前的 webRTC session 。

但是，在使用 React 的 WebRTC 应用程序中，可能不同的组件需要访问 RTCPeerConnection 对象(例如，它可能在应用程序中的顶级组件的挂载上实例化，但随后在某些 UI 组件中实例化，例如模式在接受调用的树的深处，你想调用 RTCPeerConnection 上的一个方法来创建对收到的 webRTC 报价的回答。或者一个深层嵌套的组件可能需要发起一个调用)。唯一的解决方案是将对象作为 Prop 传递到组件树中吗？有没有办法对这样的复杂对象使用 redux？

更新:考虑下面关于使用中间件处理 socket.io 的答案，让我重新定义我原来的问题:如果我在顶级组件中有一个 RTCPeerConnection 对象作为状态，那么构建中间件是否有意义处理最终必须以某种方式接收的分派(dispatch)调用 如何引用原始 RTCPeerConnection 进行方法调用，例如 setRemoteDescription？

Answer 1

在 Redux 应用程序中，类似“套接字”的连接对象(websockets、Firebase 等)的标准位置是在中间件中。需要告诉套接字做某事的应用程序的任何部分都可以调度一个被中间件拦截的 Action ，中间件可以调度 Action 来更新状态以响应接收到的消息。

Middleware - Sockets and Adapters 中有许多用于各种套接字的中间件的现有示例。我的部分Redux addons catalog .

更新

这是一个 RTC 中间件可能是什么样子的简单示例。该代码完全未经测试，但这应该可以说明这个想法:

function createRtcMiddleware() {
    return (store) => {
        let rtcPeerConnection = null;

        return (next) => action => {
            switch(action.type) {
                case "RTC_CONNECTION_CREATE": {
                    const {rtcConfig} = action;
                    rtcPeerConnection = new RTCPeerConnection(rtcConfig);

                    rtcPeerConnection.somecallback = () => {     
                        // maybe dispatch a Redux action in response to 
                        // a received message                
                    };

                    // Do not pass the action down the pipeline, since only 
                    // this middleware cares about it
                    return;
                }
                case "RTC_CONNECTION_SET_DESCRIPTION": {
                    if(rtcPeerConnection) {
                        rtcPeerConnection.setDescription(action.description);
                    }

                    return;
                }
            }

            // If we don't care about it, pass it down the pipeline
            return next(action);
        }    
    }
}