I'm developing an application using React Native + Redux and Redux Thunk. In one of actions, a large json data is fetched from our server and then dispatched to the store. When the dispatch happens, the JS thread frame rate drops from 60fps to 0 or 1 fps and so all touchables and buttons become not responsive and it's impossible to navigate through the app for a couple of seconds until the dispatch concludes and everything become normal again.
We've already made sure that only the components that needs this reducer data are re-rendering but the problem persists.
The data we are downloading is a json similar to a Map that may have hundreds or thousands of values.
Is there any way I can make React Native and Redux deal with this kind of data without dropping frames
"[...], there's nothing inherently slow or inefficient about how Redux is implemented. In fact, React Redux in particular is heavily optimized to cut down on unnecessary re-renders [...]"
Shouldn't be a problem for react-redux. Try to optimize your overall component structure:
Implement shouldComponentUpdate()-Method or PureComponents to get away from pointless rerenders. You could also consider designing a normalized redux state.
Split components in many individual pieces before connecting to the store.
Avoid overfetching and optimize lazy loading. You won't be able to display those data all at once.
This repository contains all articles treating the subject of 'Performance & Redux'. It's worth a visit ;)
Related
I couldn't find too much information about my question after googling a lot. So maybe somebody has an answer.
So I use redux and redux-saga in my react-native app. I store a countdown timer state in the store because I have to persist the timer state.
The redux store state cca. over 15MB because the user has a lot of data while using the app. I recognized, that the JS Thread has a huge drop rate if an action is called and the store state has been changed. I tried with different sizes of data and I think the store size and the frame rate drop are in connection.
Does anybody have the same experience or any solution for this issue? I checked a lot of performance blog posts about that but nowhere could find a solution for this effect.
I am thinking about migrating to Zustand where I can apply separated little chunks for the global state and maybe it has better performance, but in the redux docs if I check the performance topic I can see a much bigger state like mine. So I don't have any idea at this point.
Otherway I checked my render state on these actions maybe it causes this but nothing renders unnecessarily.
So my conclusion is that when the new state is returned for some reason always generated a new large object which can happen slowly if the state size is over 15-20Mb.
Currently I have a large list of data (500 Rows) that at times many records can be updated a second. I'm using firebase's Real time Database. I am using React and Redux and basically whenever a record is changed, I fire a dispatch event to update the state in my app. When there are many records being updated it slows down and almost crashes the browser.
I've narrowed down my performance issues to it trying to dispatch 200+ actions at once. But since it is websockets/firebase I have no way of getting these updates in groups.
I am wondering if there is a library to use that will queue the dispatch requests and update the state one at a time, in order. Instead of trying to do it all at once.
Are these issues by any chance occurring in development with Redux dev tools also running?
Redux is fairly optimised to handle large data sets (particularly if you normalise your data structure). However, if you are dispatching a large number of actions and also have a large amount of data in your Redux store, using Redux dev tools can give a somewhat false impression of poor performance.
In a production build of your application there would only ever be one instance of your Redux state at a particular moment. Hence the first of the three Redux principles; single source of truth.
The difference whilst using Redux-dev tools in development however is that the dev tools keep a history of your actions and the state for each action dispatch you trigger. This subsequently can lead to large amounts of that data filling up your browser’s memory and thus giving the perception of poor performance.
You can also take a look at the Redux documentation on performance which has several further suggestions for how you can optimise your application.
If you would also like to show us how your data is structured in your reducer, or how you are handling your action dispatches, perhaps we can make further suggestions to improve your performance.
What is the difference (benefits/cons) of using Vuex vs a service for state management.
I am working on an application that displays a catalog of items. These items are fetched from an API. At the moment users have the ability to apply filters and sort the items.
I am using a service to handle updating the view based on what filter the user applies. The items are filtered on the back end so each time a filter is triggered an update method fetches the items from the API.
There's a few levels of component nesting for this application (and these are reused among diff pages with sim functionality) and I used an event bus as a quick way to handle the events and test the API endpoints, but now I need to use Vuex to handle the state.
I am starting to write the Vuex store and I am noticing there's quite a bit of functionality that I'm transferring over from the service.
I would like to know how the too differ?
I'm relatively new to VueJS, so please take this with a grain of salt.
I think it depends on the size of the app, as well as the complexity. If you're emitting a lot of events, using state makes sense because you have a single source of truth (a single file, literally) for your app state vs an event bus which will have to be imported into every component. From the Vuex site,
If you've never built a large-scale SPA and jump right into Vuex, it may feel verbose and daunting. That's perfectly normal - if your app is simple, you will most likely be fine without Vuex. A simple global event bus may be all you need. But if you are building a medium-to-large-scale SPA, chances are you have run into situations that make you think about how to better handle state outside of your Vue components, and Vuex will be the natural next step for you. There's a good quote from Dan Abramov, the author of Redux.
Hope this helps. Good luck :)
I'm creating an audio-visual app for performances at clubs/parties. It involves webGL animation that runs at 60fps.
The animation responds to multiple parameters that could be constantly changing every second (e.g. The size of a spinning cube could be pulsing to music). As an example, there may be 20 parameters, all changing sixty times per second. These parameters are represented in the UI as numbers/visual bars.
I'm using React/Flux/NWJS to do this and it works fine. However I really like Redux and would like to change the data flow to the Redux model.
My question is:
Will updating the store in an immutable way (e.g. replicating it for each change) affect performance, when it could be changing more than 60 times per second? If so, is there a way I can bypass this for certain parts of the app and just use Redux for the less frequent changes to the app.
If you're using WebGL for your visuals, you may keep Redux but skip React all. Redux is independent from React, you are free to use its semantics and then do something when the Store is changed by registering a callback with subscribe.
http://es.redux.js.org/docs/api/Store.html#subscribe
It's not clear to me the aspect of your app, will be both the visualization with WebGL and the sliders/controls present at the screen at the same time?
If they are, you can still have a React app hosting your UI controls and a separate DIV containing your canvas. The React part will use standard Redux to keep the parameters state, and your WebGL independent code should read from the store on every requestAnimationFrame and render your scene.
You could also use a Redux middleware that queues actions and dispatch on requestAnimationFrame, as suggested in the docs here (see the rAF scheduler example)
http://redux.js.org/docs/advanced/Middleware.html#seven-examples
In Flux every action should be handled by the dispatcher.
What about an action that doesn't alter the view or the markup, such as "scroll this element into view"? What is the "Flux-way" of handling such a scenario? To by-pass the dispatcher? Or to handle it in the dispatcher without involving the stores or the components?
Flux is really more about application state management, and is not at all about the details of what components are rendered in the view. That's the domain of React. Flux simply assumes you have some kind of reactive view layer -- usually that's React.
Application state is not the same as component state. Application state is something that needs to be known in multiple components. For component state, React's this.state is perfectly adequate. An input component is a good example of something that might need this.
So in your case, if only one component needs to know the scroll position, there may not be a good case for moving that state to a Flux Store. But as soon as that needs to be known in multiple components -- especially components in different branches of the tree -- you probably want that state being managed in a Store.
The other issue your question raises is the role of Flux Actions. A Flux application always uses Actions as the origin of the data flow. There are a lot of good reasons for doing this: stable application state, keeping the app resilient to new features, keeping it easy to reason about, undo history, reconstitution of application state, stateless view components, etc.
Occasionally people want to write as little code as possible and they use a callback passed between components to change this.state in the parent component instead of dispatching a new action to go through the Flux data flow. I find this to be mixing the view and state management layers of an application, and while expedient, this can lead to a lot of headache. It isn't very flexible in the long run, because now the state is coupled to these few components. Building up a Flux data flow from the start is much simpler in the long run, and much more resilient to new features. That said, it also requires more investment in code up front.
If your app doesn't need to know about scrolling (seems rare that it would), there's no need to fire an action. Since Flux is really there to handle data flow (and subsequent changes based on that data flow), it doesn't need to know about every action that occurs.