3 ms·

I actually find it easier to reason about my components when I can trace data sharing in my hierarchy rather than allowing components to cheat and circumvent sh

I actually find it easier to reason about my components when I can trace data sharing in my hierarchy rather than allowing components to cheat and circumvent sharing state in their common ancestor. I think it's idiomatic React to construct hierarchies of functional components topped by very few stateful components. Using connect() to turns components deep in the hierarchy into stateful components can only lead to a less declarative dataflow that tightly couples those components to Redux for very little gain. If you're having difficulty moving components around because of state consider that you may be thinking too statefully and should try to find a less stateful way to describe your UI, or that the UI you have constructed does not adequately group related pieces of data and functionality together, which will lead to a confusing UX.

qudat 9y ago
I get what you're saying but for large react applications using Redux helps to dramatically reduce state complexity and increase maintainability. Having one function 5 levels deep that receives its props from a top level function means everytime you add a prop you have to modify 5 function signatures to get that new data. That quickly becomes unsustainable when you have 10+ layers. What happens when you want to modify the prop that is set in the parent? You have to pass through a callback function that will modify that parent props and then trigger a re-render. Very quickly you end up with problems that flux/redux/mobx try to solve.
learc83 9y ago
There is no way you're maintaining anything more than trivially complex apps like this. It was never built to be used that way. Passing down chains of attributes and functions through 5+ layers isn't idiomatic React because React was created with Flux in mind--this is not the intended methodology. >If you're having difficulty moving components around because of state consider that you may be thinking too statefully and should try to find a less stateful way to describe your UI That is a meaningless platitude. State exists, you can't remove it. No matter how much you minimize it, you're going to eventually end up passing props down through an arbitrarily large number of layers if you have no state management system in place. Language designers realized this was a problem decades ago--it's why we have scoping rules. Passing down chains of arguments through layers and layers of functional calls is unwieldy. And it's worse when each one of these functions is directly producing user output.

qudat 9y ago

I get what you're saying but for large react applications using Redux helps to dramatically reduce state complexity and increase maintainability. Having one function 5 levels deep that receives its props from a top level function means everytime you add a prop you have to modify 5 function signatures to get that new data. That quickly becomes unsustainable when you have 10+ layers. What happens when you want to modify the prop that is set in the parent? You have to pass through a callback function that will modify that parent props and then trigger a re-render. Very quickly you end up with problems that flux/redux/mobx try to solve.

learc83 9y ago

There is no way you're maintaining anything more than trivially complex apps like this. It was never built to be used that way. Passing down chains of attributes and functions through 5+ layers isn't idiomatic React because React was created with Flux in mind--this is not the intended methodology. >If you're having difficulty moving components around because of state consider that you may be thinking too statefully and should try to find a less stateful way to describe your UI That is a meaningless platitude. State exists, you can't remove it. No matter how much you minimize it, you're going to eventually end up passing props down through an arbitrarily large number of layers if you have no state management system in place. Language designers realized this was a problem decades ago--it's why we have scoping rules. Passing down chains of arguments through layers and layers of functional calls is unwieldy. And it's worse when each one of these functions is directly producing user output.