Should I store high-throughput, structured sensor data in redux store?

Question

I've recently started using React and so far I have built a couple of apps, including one realtime application for manipulating and visualising sensor data. This data consists in high-throughput, structured JSON frames coming from websockets at 100Hz-200Hz.

As my app is quickly growing in complexity, and after learning about Redux through official docs and Dan Abramov's courses, I have found the use of Redux very compelling to manage the visual state of the app, routing, server information, etc.

In my React-non-Redux app everything is kept in local state, but this had a cost in the architectural design. Now, I would like to start refactoring the app to integrate redux. With my limited knowledge at this point, I'm stuck at this architectural decision about where to store the sensors streams' data and the impact on the application rendering and processing performance.

In redux docs there rules of thumb for determining what kind of data should be put into Redux:

• Do other parts of the application care about this data? [YES]
• Do you need to be able to create further derived data based on this original data? [YES]
• Is the same data being used to drive multiple components? [YES]
• Is there value to you in being able to restore this state to a given point in time (ie, time travel debugging)? [YES]
• Do you want to cache the data (ie, use what's in state if it's already there instead of re-requesting it)? [MAYBE]

There have been a couple of threads discussing this, but without any definitive answer. I'm also unable to comment on this (SO noob here):

• Should I be concerned with the rate of state change in my React Redux app?

• Visualizing ImmutableJS data from Redux store in a graph

I have discovered many different ramifications that I need to learn, including middleware, RxJS, etc. I would like to push development further, but as all of this will take time to grasp, I would like to refer to the community for some directions.

Thanks in advance!

Answer 1

I'm currently using redux to provide data for widgets and I would say the incoming rate is somewhere around 80-90 hertz and I'm still getting 60 fps on widget canvas'. Like Dan said in his post, there is nothing inherently slow about using redux. However updating your UI 200 times a second is completely unnecessary, I would at least add some middleware (if you don't want to have a server) to redux to congregate updates to at most 60 times a second. Redux might not be that slow but trying to render 200 times a second certainly will be.

I will say however that I recently had to make the same decision you are and saving the datastreams in redux made accessing them across my application much simpler.

I found that using web workers was a good way of combining data into a single update. If you haven't already I would check them out https://developer.mozilla.org/en-US/docs/Web/API/Worker. If you decide to go in that direction it will probably help a lot with performance since the workers will be handling the websocket connections directly and causing action dispatches to redux in a more controlled manner.