Where do long-running processes live in a React + Redux application?

Question

Where should long running processes "live" in a react+redux app?

For a simple example, consider a class which sends and receives messages over a websocket:

class WebsocketStreamer {   sendMessage(message) {     this.socket.send(…);   }    onMessageReceive(event) {     this.dispatch({         type: "STREAMER_RECV",         message: event.data,     })   } } 

How should the lifecycle of this class be managed?

My first instinct is to keep it on the store:

var stores = {   streamer: function(state={}, action) {     if (action.type == "@@INIT")       return { streamer: new WebsocketStreamer() }     if (action.type == "STREAMER_SEND")       state.streamer.sendMessage(action.message)     return state;   } } 

But, aside from being a bit strange, there's also no way for the WebsocketStreamer to get access to the dispatch() function, and it breaks hot reloading.

Another potential solution is to keep it in a global somewhere:

const streamer = new WebsocketStreamer(); 

But that has obvious testability implications, and breaks hot reloading too.

So, where should a long running process live in a react + redux app?

Note: I realize that this simple example could be built with just stores + action providers. But I would specifically like to know where long-lived processes should exist in situations where they exist.

Answer 1

In my experience, there are two options. First, you can pass store to any non-Redux code and dispatch actions from here. I've did this with socket connection and all was fine. Second, if you need socket or whatever to change with redux actions, it looks like a good idea to put connection and it's management in custom middleware. You'll have access to store API as well as will be informed on all actions dispatching, so could do anything you need to.