We have container components directly managing connections to sockets, but since ultimately when data is received it gets dispatched and held in redux stores, there's no need to have this logic in the container. We'll move it to the action creators, where all other API-interfacing logic is encapsulated for the web client. The container will only need to invoke actions for subscribing and unsubscribing...then receive the data as usual through props/state from the connected redux stores.
We have container components directly managing connections to sockets, but since ultimately when data is received it gets dispatched and held in redux stores, there's no need to have this logic in the container. We'll move it to the action creators, where all other API-interfacing logic is encapsulated for the web client. The container will only need to invoke actions for subscribing and unsubscribing...then receive the data as usual through props/state from the connected redux stores.