Does Flux/Redux concept about application state put bounds on the size of application?

Question

In Redux (React Flux implementation) guide https://redux.js.org/basics/reducers it is said, that

In Redux, all the application state is stored as a single object

My questions are:

• How seriously we should take this principle? E.g. my application can have multiple entities like Person, Invoice+InvoiceLine, Article, etc - full set entities for traditional ERP application. Each entity is handled by separate form inside SPA application. Doe we really need to store each active entity (each invoice under editing) in single central Redux store and access its properties inside InvoiceComponent, ArticleComponen as this.props.... objects? Or maybe it is better to load those enties into this.state objects (using Redux store as temporary store where objects sit during time between retrieval from backend till going to the components) and uses central store for application wide configuration parameters (e.g. logges user data, preferences, etc.)?
• If we should put almost everything into Redux store, how this impact the possible limits of application and possible performance of application. What is diferrence between Redux store and the God's class?

Maybe SPA is just not appropriate for the frontend of ERP type applications whose characteristic is the huge schema of interrelated entities?

Answer 1

Redux does not advocate anything other than the minimum required for your application to work.

It's a tool (mostly) to pass shared data around in an easy and simple way.
You should think about how you want to use Redux in your application. Figure out what data needs to be shared. With an ERP I'm guessing a lot, but not necessarily everything.

Though Redux promotes a single source of truth it is possible to have multiple stores that you can then combine if needed. It depends entirely on how you design your solution.

Nothing prevents you from having a ton of data as local state or even as local props in your components and then only pass data that other components will need into the Redux store.

In short: Don't put everything in the Redux store. Only what multiple (i.e 2 or more) components will need.
If that turns out to be almost everything, then that is what it is. The module react-redux will help you control what exactly your components will get from the store.

Also consider the data you expose from the backend.
Do you truly need everything from the Person entity to be in the frontend? Ask yourself those things and see what you can minimize. It is often seen that excesive amounts of data are exposed when they don't need to be.

Regarding scalability; javascript in general is very scalable and if minimized and optimized properly. Redux is no different and is being used in very large SPAs.

The question has also been brought up back in 2016 on Redux's github with the issue #1303 Redux Performance with Large Store and frequent updates which in essence asks you to consider additional modules such as redux-ignore and redux-batched-subscribe.