Comment by tomduncalf | Hacker News Reader

Comment by tomduncalf | Hacker News Reader

Parent Full thread

This makes me sad as I can’t help feeling that Redux being promoted (earlier on in React’s life certainly) by the community as the de-facto way to manage state has caused a huge amount of pain for newcomers.

This isn’t the fault of the Redux authors - it does what it does well, and they’ve always said it’s not intended to be used for everything - but I honestly feel (and have anecdotally observed a few times) that being introduced to the complexity of Redux completely ruins people’s first steps in React (the two are often seen as inextricably linked to newcomers).

Personally I feel the community should be pushing people much more towards lighter weight solutions such as component state and MobX for when the application grows.

I know Redux has theoretical advantages but in the real world I’ve always found it a large burden and would personally use MobX in preference every time (which isn’t to say MobX also doesn’t have its rough points, but it’s much more intuitive).

I suppose the “early on in React’s life” part is relative. The era before Redux, though, was far worse. There were so many flux implementations with very different answers for even the most fundamental questions (like where to put data fetching and side effect code), and none of them developed a community large enough that these answers were sufficiently documented and discoverable.

Competition is good, obviously, and we certainly still have that, but I much prefer this era where there are a relatively small number of competitors in the space, each with (mostly) well-baked answers to common questions and mature and active communities.

So our React site is fairly static, but as it grew we had more and more state to manage across components, and more of it trickling down; in some cases state would come from fairly high up in the structure, and have to be ingested pretty far down the component chain.

So as I read the React docs, I discovered childContext, and I started using it. Some of my coworkers would stick to passing props along 2 or 3 or 4 layers down, because every time I'd point childContext to them, they'd point to the part in the docs where it says it's experimental tech and that it could be removed in the future. I'd point out that the React devs have a very sane code-breaking policy and we'd just cross that road when we'd get there. It's not like we're aggressively updating to the latest release anyway. Some other people would suggest using Redux, but would agree with me that we just didn't manage _that much_ state.

(We also have a React Native app, and as we manage more state in there, we did implement Redux, though it still bothers me as a tech.)

Anyway, fast forward to last month, where I read Abramov explain that Redux actually uses childContext!! So:

1) there's no way they'd just rip it out of React without warning,

2) if childContext works for you, don't worry about the complexity of Redux, just pass down state and a few state-modifying functions in childContext!

You might want to go read the release notes for React 16.3 ( https://reactjs.org/blog/2018/03/29/react-v-16-3.html ), which discuss the history of the old context API, and its new replacement.

Old context will continue to exist through React 16.x, but will be removed in 17.0. Meanwhile, we've got a proof-of-concept PR open for React-Redux to switch it to use the new context API instead ( https://github.com/reactjs/react-redux/pull/898 ). Given the other changes related to React 16.3+, we're likely to put out a React-Redux 6.0 that includes the context usage changes, and make it 16.3+ only.

All that said: you really _should_ stop using the old context API, upgrade to React 16.3, and switch to the new context API instead. It solves the issues inherent to the old APIs design, and is the supported approach going forward.

Absolutely. That'll go in lockstep with upgrading to 16.3 :)

Reply on news.ycombinator.com