I am working on a React and Redux application that uses ImmutableJS to store all of it's state.
The app receives data from a sensor at about 100 Hz. I need to draw a graph that updates in real time and displays this data.
I have been using React-Vis for the graph, the problem is that it takes an array of objects and not an ImmutableJS data structure.
I have solved this by converting the ImmutableJS data structure to an array like this:
const data = this.props.HEGPercentage.toIndexedSeq().toArray()
This works but the problem I am encountering is massive lag if I run this with real data, I think because it has to create a new array all the time.
How can I create a high performance solution for this and still use ImmutableJS?
Converting between plain JS objects and Immutable.js objects can be very expensive. In particular, the fromJS() and toJS() operations are the most expensive operations in the Immutable.js library, and should be avoided as much as possible (and especially in Redux mapState functions).
It sounds like you're already at least somewhat on the right track. Use memoized selectors to cut down on expensive transformations, try to round those numbers if possible so that there's fewer meaningless changes, and cut down on the total number of updates overall.
My React/Redux links list has a large section of articles on improving performance for React, Redux, and Immutable.js, which may be helpful.
It's also worth noting that I personally advise against use of Immutable.js for a variety of reasons.
Related
I'm currently working on a single page dapp for lucky bunny farm, it all works and will be released soon. But i'm wondering if maybe i've engineered it entirely wrong because i have put most of the business logic within a collection of useEffects (6). Because i dont have any other pages on the site i've not created hooks as i would in other situations because there's no benefit from a writing code point of view.
It seems to me that having 6 useEffects working off the state variables i've set might be a little much, is there a performance gain from reducing them or doing something else? I have created components for the various on page assets and those internally have their own state and useEffect hooks too. What's the danger in a "large" number of these hooks and at what point should i consider optimising for performance.
Or am i over thinking this and actually this is quite normal and i should only worry when i have say 20 hooks all doing their own thing.
Additionally, i tend to use state for single variables instead of objects, is there a performance gain from using a single state with an object.
So to use an example i have the following states:
dappActionStarted
dappActionCompleted
dappActionError
Would it be more efficient to have something like:
{
started
completed
error
}
And then do a single useEffect for that object as opposed to the three i would need to manage 3 seperate state vars.
I'm building an interactive plot in React where the user can select multiple variables and add them to a single plot. Each of these "variables" represent scientific data and are stored as arrays with 100k to 3 million elements.
I don't feel very inclined to store these variables in the React state as their contents never change and I'd prefer to control when the UI needs to re-render manually instead of letting React automagically traverse these arrays trying to find out if they have changed, which renders my application unresponsive.
Is there any preferred way of storing this data and sharing it with React? Right now I just store everything in a global variable.
There aren't many places you can store it though. If the data never changes, there's no downside in storing it in state, no changes means no re-renders. It sounds like there's quite a bit of it, so you can't store it in local storage due to limits. If you build a data set inside React by doing a bunch of API calls, revisit the API itself - it should return the data you care for, rarely a bunch of data segments you have to splice together yourself.
I'm developing a software which is drawing some elements on the screen which is using by mechanical engineers.
I'm string my project data in reducer store. This project data has tons of objects, arrays etc. I mean for each element on the screen, there is a data stored in project.
When user makes an action, I must recalculate project and set it to redux store again for example;
...
case SET_ACTIVE_UNIT:
let unit = action.unit;
project = state.get('project').toJS(); //I'm using immutable
project = ProjectLogic.addActiveUnit(project, unit, action.shiftKey);
return state.set('project', fromJS(project));
...
Ok, you will say that this kind of usage is not right. Because I'm reading all data and reseting it to reducer whole data. You will advice me to use state.setIn but it is really imposible. Beacuse in addActiveUnit function will recalculate project, %20 of project data will be changed. So, I can't handle this change state.setIn
My problem starts here; if there is 60-80 elements drawing on the screen after return state.set('project', fromJS(project)); rendering performance slows down. Every new items gets it worse.
How can I handle this problem?
Thanks all
As a general observation, toJS() is considered to be the most expensive API in Immutable.js, and should be avoided as much as possible.
My initial advice would be to not use Immutable.js.
Instead, you might want to look at using immer to handle the immutable update logic.
Also, our new redux-starter-kit package uses Immer internally.
Beyond that, I'd suggest doing some profiling to see where exactly the perf bottlenecks actually are.
I have at least two approaches to solve a problem.
Repreform calculations inside views on each update (map, filter, find)
Keep an "CurrentState" object inside my redux state.
I choose to create a CurrentState object that stores my calculated result (It calculates the results inside the reducer function).
Approach 2 saves processor calculations, but it feels dirty.
is it considered an antipatern to have a CurrentState object (updated from the reducer) inside the state?
Thank you in advance!
Not totally clear from your question - but I assume that you are talking about situation, that you can compute "result" from other data in your store and asking if storing it (redundantly) in store is good pattern.
Well, generally I would not recommend it as keeping redundant data in store can lead to inconsistent data bugs - if you forgot to keep your data in sync (e.g. when you or someone else working on the project would change one data and forget to change the order place).
The standard patter for this is usually to use selectors and memonization (see https://github.com/reactjs/reselect). The idea is to keep only normalized data in your store but to use selectors in your views. Selectors are responsible to "cache" (memonize) extensive computation. Another advantage of selectors is that it provides level of indirection for your application and you can easily evolve your state (as the project grows) without affecting your whole application. On the other hand for small and one time projects selectors can be just "another" boilerplate - but in general I recommend to use them.
This was a hard anti-pattern.
If you are reading this chances are you don't fully understand redux and I would like to recommend
https://github.com/leoasis/redux-immutable-state-invariant
While writing an engineering application with a React Redux framework we have come across an issue of having a database of products that have functions to work out their load capacities and other properties. I know it is not a good idea to load the functions into the store and retrieving the functions from another location in the reducer breaks purity and makes the reducer much harder to test.
Is their any React Redux way of supplying the reducers with the database of product functions as a parameter, or similar, without putting them in the store and without breaking purity?
Edit:
Each of the products have functions that might describe for example the relationship between jack extension and load capacity. This relationship is usually non-linear and has a graph that will relate the capacity over its extendable range. We have used curve fitting tools to match these graphs to functions over their range. I would like to be able to use these functions in a reducer such that when someone selects a product and extension we can obtain the capacity and check its suitability against other calculated loads in the state.
A few thoughts:
Yes, including non-serializable items such as functions in actions or the store state is definitely discouraged, on the grounds that it will generally break time-travel debugging. However, if that is not a concern for you, it is something you could do. See http://redux.js.org/docs/FAQ.html#organizing-state-non-serializable and http://redux.js.org/docs/FAQ.html#actions-string-constants .
Another approach would be to keep the math functions in a lookup table, and include a function name in the action that can be used to look up the correct math function for use in the reducer
A third option is to do more of the work in thunk action creators, and put the results of the calculations into the action.