4 ms·

> With all due respect to the Redux team, I simply don't think Redux scales in large applications. Very much disagree. Redux, to it's, credit, almost made deve

> With all due respect to the Redux team, I simply don't think Redux scales in large applications. Very much disagree. Redux, to it's, credit, almost made development boring to me in the sense that we had an unreasonably large application that could scale and scale and scale without any concern whatsoever. I've worked with other patterns and libraries since and nothing compares to how easy it was for our team (of varying degrees of experience) to jump in anywhere and make additions that made sense through time. And like the author of the article mentions, all of our devs grew in general because of what they learned from it's patterns / concepts.

WA 7y ago
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.

WA 7y ago

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.