Hacker News Reader

Comment by mephitix | Hacker News Reader

I started using Redux with container components and dumb presentational components - this worked and scaled well.

Eventually though some containers started to have their own state, derived from props.

Ultimately I was left with the feeling that I wasnt really getting the full benefits of redux (time traveling, centralized middleware, etc) without moving all state in my app to Redux.

I think this is how teams get trapped by Redux - the pursuit of having nice dev accordances like time traveling leads them to adopt Redux everywhere and just by Redux’s nature (immutability, declarative actions) it ends up complicating things way too much.

I think the article I’m most grateful for is Dan’s article on container vs presentational components. Sticking to that philosophy let me adopt Redux and try it out but still have the majority of my app in dumb, non-Redux presentational components. So now it’s easier to remove Redux if I need to.

View on HN

We do try to emphasize that it's completely up to you how much or how little state you actually put into Redux: https://redux.js.org/faq/organizing-state#do-i-have-to-put-a... .

I've certainly talked to people who literally put every single value in their app into Redux (often in conjunction with _only_ using functional components). I can understand why they might choose that approach, but to me that's over-opinionated. Most of my app-type data does go into Redux, but it's absolutely fine to use React local component state for whatever doesn't need to be shared.

That's one of my favourite parts of Redux is how flexible it is, use a little bit here and there where it's appropriate. The current project I'm working uses Redux to manage all of the websocket communication but that's it.

I think you should generally start by putting everything into Component state, and only move stuff to the store if you find yourself needing to do a lot of prop-drilling.

Time travel is nice, but it is not worth putting everything into your Redux store.

But if you want to do prop-drilling then the advice from the React team is that Redux shouldn’t be used just for that. (Context API is the suggested approach).

FTA: “If you're only using Redux to avoid passing down props, context could replace Redux - but then you probably didn't need Redux in the first place”

I use Redux sort of like Core Data (in iOS world) - I just use it mostly to store external data since it’s valuable to track the modifications to and morph (via reselect) specifically that kind of data.

If I ever have other local state it just sits in components. But most of the time components have no state at all.

Yeah, sorry, I wasn't clear.

My point was mostly that you shouldn't be afraid to let state live in Components and that should be your first instinct even if you are already using Redux for any one of its benefits.

There are other reasons besides prop-drilling to offload state into the store, but don't do it if your only reason is "I want to make debugging marginally easier".

Reply on news.ycombinator.com