Interesting. I didn’t write a big app with Redux, but one potential scaling issue I found is this: You kind of have to think about the structure of your state

Interesting. I didn’t write a big app with Redux, but one potential scaling issue I found is this: You kind of have to think about the structure of your state tree beforehand. If you later discover that you sliced your state in several sub-trees with respective reducers, but the reducer of sub-tree A now needs to get some info from sub-tree B, things can get confusing. Or put another way: if you think parts of your state are independent from other parts and this later turns out to be wrong, you need to refactor quite a bit or have to live with an improperly separated state. I guess scalability depends a lot on the nature of changing requirements and how experienced you are to define the state tree. This is actually something where I see the biggest learning curve. For example: say you pull data from your database. This could be considered the normalized state and everything else is just derived from that state. However, in your UI, it doesn’t make sense to work directly with the original normalized DB state, but some kind of semi-normalized intermediate state. Furthermore: you could put computed/derived state directly in the state tree, or use something like the Reselect library. Since there are endless possibilities to design this, it can be tough to learn any of this. Most tutorials also deal with very simplistic state trees.