长时间运行的进程在React + Redux应用程序中的位置在哪里？

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.

Answer 2

I'm doing something similar with websockets. In my case, I simply wrap the websocket client in a React component that renders null and inject it as close to the root as possible.

<App>
    <WebSocketClientThingy handlers={configuredHandlers}/>
    ....
</App>

Here's a quick example. It's pretty naive, but get's stuff done.

https://github.com/trbngr/react-example-pusher

Quick note: The websocket doesn't live in the store. It's simply there and publishes actions.

EDIT: I decided to explore setting the client (long-lived object) into the global state. I gotta say that I'm a fan of this approach.

https://github.com/trbngr/react-example-pusher/tree/client_as_state

Answer 3

I opensource a demo issue tracker with long running ops using React/Redux/Node,all the involved code but is open sourced and MIT. Sometimes I need to pull or push the repo and depending on the connection this might take a long time, this is where the next long running operation comes in.

Overall the key points of the approach are:

• A redux store with the active operations and its status.
• A redux store with events of the operations
• Initialize the operations store with all the ongoing operations during the page initialization
• Use a http events server to update a operation status, either data, error, complete, progress, etc.
• Connect the components like buttons to the ongoing operation status.
• For each component keep a list of involved operations and parameters, if the operation and parameter match... change the button state to loading/done/etc..
• Change the status of the operation store with the events update or request results (I am using a GraphQL and all the mutations returns a "Operation" type)

The involved repositories are:

• https://github.com/vicjicaman/tracker-common ---> GO TO ---> src/pkg/app-operation/src
• https://github.com/vicjicaman/tracker-app-events
• https://github.com/vicjicaman/tracker-operation
• https://github.com/vicjicaman/tracker-events

This is how it looks like running: https://user-images.githubusercontent.com/36018976/60389724-4e0aa280-9ac7-11e9-9129-b8e31b455c50.gif

Keeping the state this way also helps you to:

• The ongoing operations state is keep even if the window is refreshed
• If you open two or more windows and perform operations in one window, the state of the running operations and UI for all the windows are sync as well.

I hope the approach or code helps.