in the Redux documentation is written:
In Redux, all the application state is stored as a single object.
And that starts my problem.
I'm writing an application that will manage few entities with many data in a SPA (React + Redux) and something is concerning me in to using Redux and get some kind of lag because the quantity of data that I'll need to manage.
I don't believe that transferring all the application state over Redux would be nice, because in some way, it may consume a lot of memory, but I may be wrong.
Redux looks like (to me) so simple and so confuse at the same time and I don't if I should or shouldn't use this, but, the application will grown a lot and I have sure that it will help me to maintain the project organized as well.
Another thing that scared me is about rendering DOM element when an updated state occur. It's different from using setState() on React and as we can see in the Redux videos from Dan Abramov, he is using a forceUpdate wich isn't recommended in the React docs.
Is it possible to manage the entities in different stores but put them together just when it is necessary?
Will it consume a lot of memory if storing all the application state in a single store object?
What's the best way to render React components using Redux?
You've definitely got several different questions there, and you are over-thinking things :)
First, caching data on the client-side is no different in Redux than with any other Javascript framework. In fact, caching data with Redux will likely take up less memory than it would with something like Backbone, because a Redux app will store plain JS objects and arrays rather than wrapping the data in model class instances. There's also no difference size-wise between splitting that data between multiple stores, and combining it all into a single state tree in one store.
Now, how much data you cache is up to you, but realistically you could easily load tens of thousands of records into a client app over time without having issues.
Second, don't confuse the small examples that Dan shows in those videos with how the React-Redux library really works. Dan was trying to illustrate some basic ideas, not show production-grade code. If it helps, he actually wrote a miniature version of connect that shows the basic idea of what connect actually does. Meanwhile, the real React-Redux library is highly optimized (and does actually use setState internally once it knows the data has really changed).
Finally, while you can create multiple stores, the Redux FAQ advises to only use one store, for several reasons.
I recently published a presentation that introduces the basics of React and Redux. You might want to read through that. I'd also encourage you to read through the Redux docs thoroughly.
Also, I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics.
