Suggestion on how to expand websocket redux connection - Visualisering/Visualisering GitHub Wiki

Current functionality

As it stands now the server sends the whole redux state to all clients connected to the exposed websocket whenever one of these things happen:

• A new client connects to the websocket. See line 55-59 in app.js, where the server receives an action from the connected client and then dispatches this action. The reducer does not have a case to handle this action and therefore just returns the current state.
• Any change is made to the server redux state tree. See line 28-40 in app.js, where the server on any change to the redux state broadcasts the state to all connected client applications.

Possible expansion

While the current functionality works right now in the way that data is sent from server to client it is in many ways a very crude and unsofisticated implementation. It would be nice to have some functionality where the client could request specific parts of the state and the server could respond with the requested data and send it out only to the client that requested it.

Time did unfortunately not allow us to implement this functionality during the project but we would take this opportunity to explain how we would have wanted to do it.

A big inspiration for our app and the idea to create a fullstack redux application comes from Tero Parviainens blogpost "A Comprehensive Guide to Test-First Development with Redux, React, and Immutable" and in it he has a chapter that should be very helpful for implementing this expanded redux-websocket functionality, namely "Sending Actions To The Server Using Redux Middleware". Go read the whole blogpost if you have time for it (and we are talking serious time here - it's a long one!) or just skim through it and focus on the chapter linked above.

In this chapter Tero walks us through how to implement a redux middleware that checks for remote-tagged actions and dispatches these not only on the client side application but also send it to the backend. What we think should be possible is to alter this flow to the needs of the iViz application, where local actions tagged with remote could be dispatched on the client application when a visualization component mounts and ask for any new data and the backend respond to this with the requested data.

We hope that this idea can be helpful to the person that takes on the challenge to actually expand this functionality sometime in the future.