Hacker News Reader

Comment by toprerules | Hacker News Reader

When I first came to React my understanding was that React/Flux were all but a package deal, and that I better use Redux because it seemed so popular. Redux quickly became a pain point in terms of boilerplate and added cognitive load. Now a top level stateful component works for 90% of my use cases.I feel the same way about React Router. Maybe if you're building something quite large or complex these prepackaged tools make sense, but I personally have gone the way of Golang and started to prefer a little copying over adding an extra dependency and I've found that React is wonderful by itself. I encourage anyone who will listen to try ditching Redux in favor of a single top level stateful component.

View on HN

I wouldn't recommend this at all. Sure if you have a tiny site with very limited functionality or you're learning react, you don't need redux.

But if you're using components they way they're intended, (not cramming everything into a few overloaded components), you're quickly going to be passing down props down through layers and layers. It will quickly become a maintenance nightmare.

Just imagine that you have a button component that is 5 or layers down from you're stateful component. It's getting props to control it's state passed down through all 5 levels, and it's getting functions to change the stateful component's state passed down through all 5 levels. Now what happens when you want to move the button from your side bar to your footer?

Redux solves a very real problem, there are other solutions to this same problem, but eventually any non-trivial app is going to need something for state management beyond a single top level stateful component.

How does using Redux solve the tons of props through layers problem?

Because you can use the React-Redux `connect()` function to wrap any component in your tree with a "container component" that automatically subscribes to the Redux store, extracts the data you want for that component, and passes it straight in. That way, the upper components in your application don't need to know that a leaf component happens to need a specific value and pass it down through N levels of components - that one component just grabs the data it needs from the store. A good example of this would be a list or a treeview, where every list item or treeview node is itself connected to the store.

I talked about some of the benefits of using Redux in a React application in a post I co-wrote: https://www.fullstackreact.com/articles/redux-with-mark-erik...

That sounds completely opposite to the React functional philosophy and is akin to using global variables in a regular program.

Have fun testing that!

You can test the base component or test the connected component with a dummy state. If your state is shallow, this is very easy to do.

My second problem with Redux, besides the common one about boilerplate, is precisely the mismatch between the recommended, RDBMS-like shallow store, and the typically tree-like OO nature of both the UI and the application logic. I understand that concrete containers act as adapters between the store and a given level of the application/UI tree, but this "impedance mismatch" is a real drag.

It's actually trivial to test, because all of the state is known at any time. So yes - kinda global state, but exact full state as input and exact full state out as output. Which you can test sliced into parts with as many tests as you want.

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.

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.

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.

Reply on news.ycombinator.com