Echo JS 0.11.0

> Can state management be done without the use of useState? A widespread question with over 300,000+ results on Google.

Most of which are actually results on managing state *using* useState. Because the number of results on Google stopped being directly related to your exact search years ago. Now Google offers results which are related to the concepts you mention in your query, but *not* a direct search on your exact query unless you put it inside quotes. If you do put it in quotes you will get exactly 0 results (even if you write it correctly).

But let's ignore that bit anyway...

The problem with this article is that it never explains or even mentions what the original problem or limitation of using useState is.

The article only ever says "If you find yourself keeping track of multiple pieces of state that rely on complex logic, the useReducer hook may be better." and that's all the justification it gives. And then it provides an example explaining how to use useReduce.

If you want to write about solution B being a better option than solution A, you don't just jump into explaining B. You *need* to point out what the original problem with using solution A is, or what is the limitations A has. You need to explain *why* or *when* to choose solution B over solution A. And no, useReducer isn't *always* a better solution than useState; each has their place.

But it's even worse. Because the example used in the article, the author admits, "doesn’t teach much about complex state management". So... they don't explain the problem with useState and then build an example which is, by their own admission, not a good example to show the need for useReducer.

Not the Author... that said, one advantage of using a reducer to respond to events is that you can process your logic as a pure function which is easier to test both state and changes.  It also is better in terms of separating state management from render.

If course it's at the cost of a slightly more complex implementation and requires that separation of responsibilities in a clean way, which isn't always the case in practice.

It's part of why I've been such a fan of straight Redux for state management.  It's easier to compare/contrast with a state checker system such as the original Angular where projects and implementations have tended to have many bugs related to state management in practice.

Much like tdd, it doesn't make the code cleaner or better, but does make it more painful to not do it cleanly.

Yes, I know.

But the above was not meant as a question, but as criticism of the article. While you may care enough to give an answer *here*, none of the readers of the original article will read it.