Regarding Hooks, they're fairly new so I wanted to keep the tutorial compatible with most people's codebases. I'll probably do a follow-up for Hooks in the future, but Eduardo's post looks great.
Regarding Redux, I don't think that you should never reach for it, but don't reach for it too early. In one of my recent apps, I decided to forego Redux entirely and the lack of architecture provides flexibility in deciding how everything will evolve. Perhaps Redux or another state library is the solution, but the codebase isn't big enough for me to worry about it yet.
I personally recommend using local state and context until you feel like you need something more powerful or structured. If your app is very complex and also has a large team, then Redux may be a good option for that. For most "non-Facebook-level" apps though, I think staying with context or using a simpler state library built upon context (e.g. Laco, Unstated) will work out really well.
I agree with you to keep state locally within the component, if that piece of state is only needed within that component. So don't make state "global" or centralized if it's needed only in 1 place. No disagreement there.
However ... I didn't know how the Context API works, but now that I know, it I wonder in what way it's really simpler than Redux. If I I understand it correctly, it's just an alternative way to have "global" or centralized state which you can access wherever you want, do I see that correctly?
In that case I would argue that conceptually it isn't really that different from Redux, only "syntactically" and in its mechanics, the way you program it - what it achieves it isn't that different. In the end both sort of look like a glorified way to inject a singleton object with some variables and getters/setters.
In other words, I don't really see the point, unless it cuts down a lot on "boilerplate". Redux also isn't that hard to understand or use, and it's a well known pattern. I'm never really a big fan of "10 different ways to do the same thing", it makes it a lot harder for (new) developers to understand an unfamiliar codebase.
(this is also why I'm generally a fan of the Vue framework - Vue is more opinionated and "batteries included" and mostly advises one recommended way of doing something)
Actually I could make the opposite argument: if you start out with "Context" because your app is 'simple', and later on you realize (as you said) that you'd better use Redux because your app has become more complicated, then you'll have to rewrite all of your context-based code to Redux. Then why not start with Redux right away? Especially because it isn't that hard, at least in my opinion.
So yes, I agree with you when you say "don't reach for Redux too early", but the same applies to Context - don't reach for Context too early. As long as you can manage state locally within components, or you just need to pass it down 1 or 2 levels (via props) then use neither Redux nor Context.
Once you realize that you do need centralized state, then use Redux or use Context, whatever floats your boat (but as I said I don't really see how Context is that much simpler than Redux).
Ah I see what you mean.
Yes you're correct, there is no difference in what Redux and Context API are made to do.
I also definitely agree with local state. Don't reach for Context or anything global if your components don't need that yet.
The topic of whether Context is actually simpler or if it's better to use a well-known library like Redux is for another discussion I believe. There's also different ways of implementing Redux so I think even if I make some points against Redux, it may not actually apply to every project that uses Redux.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.