Again...
You're trying to explain *CONCEPTS*... But you don't. Instead you focus on using some superficial technical details as if they were the relevant idea.
So you say things like "state is a type of object" that holds the application state. Or "Actions are a simple JavaScript object" that has "a type field that specifies the type of action to take". That is, you're using the term you should be defining inside the definition you're giving. The state is an object that holds the state. An action is an object with a property that indicates the action to take.
That doesn't work. You're not explaining things. You're just throwing words around.
You focus too much on irrelevant details. Reducer functions are expected to be pure... let's spend some paragraphs on this particular detail of pure functions. The spread operator is an easy thing to use when you want to build a new object that is very similar to an existing one without modifying the original one... super cool, let's write a whole section on this as if it was a super important thing specific to Redux reducers.
The conclusion is...
"Reducers are a crucial component of Redux state management because they allow us to construct pure functions to update specified portions of our Redux apps without causing side effects. We’ve covered the fundamentals of Redux reducers, their applications, and the core concept of reducers, state, and actions."
But this is not what the conclusion should be. Reducers do NOT "allow us to create pure functions", reducers *are* the functions we create and are expected to be pure. And no, you have not explained the core concepts.
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.
This doesn't seem to be O(1) on removing.
Removing sets #shouldArrange which then means a call to #arrange which is clearly not O(1).
The readme file in the repo itself says that it is O(n) in adding and removing and O(1) only in searching.
It also should be mentioned that it needs an additional O(n) space. I mean, if you need a certain structure for performance you most likely need to consider the cost, so I would think this should be mentioned in the readme.
Yes, they are. But contrary to what you might think it should be *very rare* that this turns out to be a problem.
If you ever find yourself thinking that you need a solution like the one presented in the article, you should stop for a moment and think again.
There's *almost surely* a better way to write your code and make it better than having to check if "this is an object and it is not null but it is empty". This code...
if (typeof value === 'object' && value != null && Object.keys(value).length == 0)
...is not good code.
> 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.
I've seen this article make the rounds in various other places. I don't mean to be rude or too hard on the author, but it's not a good article.
Mostly it's just the same handful of things that maybe 4000 other articles already commented on. There isn't anything new here at all.
The first question is quite absurd to ask as a quiz. All the explanation given is "super basic prototype chain stuff" and, of course, that helps nobody. Because there's nothing to understand about the code, there's nothing to reason about. You either know what .prototype and .__proto__ are or you don't.
The third one's explanation is... not an explanation at all. "It prints out 3 thrice since setTimout [sic] puts that log function to the next macro task queue". Yeah, so what? That's not the reason. The reason is that each log function created shares the same i variable. You can change the var to let and it would work differently. And yet it would still be true that setTimeout "puts that log function to the next macro task queue". So the explanation is wrong.
The fourth one is wrong too. You just have to copy the code and run it. It runs correctly. There's no SyntaxError at all there. If your console is nice enough it will give you a *warning* that there's some unreachable code. But it's only a warning. The code will run and it will log undefined.
The fifth one is just silly. I mean, ok... but that's a stupid quiz to ask your teammates.
The explanation on the last one is... well, I can't say it's wrong but it's really not helpful. All you should do is take the let a = b = 0; statement and explain how that works, which you don't do. You just say "b is a global variable" but you don't explain how or why or where does that come from. So for the only detail that could need an explanation, you don't explain it.
All in all, I don't think this is an article one should be sending around everywhere.
This a fairly detailed account of various examples of the usages of Properties and State.
Still it clearly fails at both producing any meaningful *understanding* and at making any *comparison*. The main problem is that the author focuses on the superficial characteristics of properties and state but never cares to actually explain the concepts themselves.
Again... You're trying to explain *CONCEPTS*... But you don't. Instead you focus on using some superficial technical details as if they were the relevant idea. So you say things like "state is a type of object" that holds the application state. Or "Actions are a simple JavaScript object" that has "a type field that specifies the type of action to take". That is, you're using the term you should be defining inside the definition you're giving. The state is an object that holds the state. An action is an object with a property that indicates the action to take. That doesn't work. You're not explaining things. You're just throwing words around. You focus too much on irrelevant details. Reducer functions are expected to be pure... let's spend some paragraphs on this particular detail of pure functions. The spread operator is an easy thing to use when you want to build a new object that is very similar to an existing one without modifying the original one... super cool, let's write a whole section on this as if it was a super important thing specific to Redux reducers. The conclusion is... "Reducers are a crucial component of Redux state management because they allow us to construct pure functions to update specified portions of our Redux apps without causing side effects. We’ve covered the fundamentals of Redux reducers, their applications, and the core concept of reducers, state, and actions." But this is not what the conclusion should be. Reducers do NOT "allow us to create pure functions", reducers *are* the functions we create and are expected to be pure. And no, you have not explained the core concepts.Yes, they are. But contrary to what you might think it should be *very rare* that this turns out to be a problem. If you ever find yourself thinking that you need a solution like the one presented in the article, you should stop for a moment and think again. There's *almost surely* a better way to write your code and make it better than having to check if "this is an object and it is not null but it is empty". This code... if (typeof value === 'object' && value != null && Object.keys(value).length == 0) ...is not good code.