TL; DR
This is bad:
function useCounter() {
const [count, setCount] = useState(0)
const increment = useCallback(() => setCoun...
For further actions, you may consider blocking this person and/or reporting abuse
In reality, this is a quite rare situation. Usually, if you want to set something - you want to set something.
Even more - sometimes, when you depend on the previous state, let say I am talking about
toggle
command, it might be a mistake to depend on the previous state.Lets imagine - you have a button, a toggle button, and once you clicked it - you toggle something. So - should
toggle
show something, or shouldtoggle
hide something would be defined when you click. If you clicked twice, some people like to double click - it shall still do the job you expected it to do. And your expectations were based on a visible state. Tada :)So - it's not an antipattern, - it's a feature.
Hi Anton!
I think that really depends of the nature of the data that you are working with... In my company we work with real-time data, and I assure you that this is not a rare situation for us. On the contrary, many times we need to update parts of the state depending on the value of other parts. Those others could have not finished updating yet, so relying on the "current state" is a common pitfall. Using the function overload is always the way to go in those situations.
Sorry but that is just not true. Try to double click as fast as you are able to in this sandbox, and then let me know how many times the double-click behaves as a click... I've tried it a thousand times with no luck. I have even tried throtling the CPU and nope, nothing.
The only way to accomplish that would be to add some debouncing into the click, which you shouldn't do because the double-click sensitivity is user-configurable and it varies a lot depending on browser, OS, etc... From an accessibility stand-point that should be something to be avoided at all costs. Basically, trying to make a click behave like a double-click or vice-versa should always be considered a huge no-no.
The idea was about - sometimes you have to synchronize actions between how they are visible to a user, and how they are visible to a system. Let's say - it's about the
source of truth
. You might pick the best source.Don't be stuck to your use cases, and argue using only your use cases. Don't deal in absolutes.
To be more concrete - I've seen many examples when developers are using the following code:
They heard that this is how it supposed to be used. Usually, I am using two constructs to solve this misunderstanding:
In my post I clearly state that:
I think that I'm a very clear about the fact that this is only an anti-pattern when your next state depends on the previous one.
Then I guess that I misunderstood you when you said that:
My response to you had to do with this statement:
Which, as I already pointed out to you before, it is wrong in many different ways: first because it's not true that by not using the function overload you would get the behaviour that you are describing, and even that was true, that wouldn't be a feature, it would be a bug... :-)
But I don't. Really, I do not. Please read my post again. I only call it an anti-pattern
That sentence appears like 4 times in the post.
Do you know of a single case where advising developers to use the function overload for those cases when they want to "evolve" the previous state would be harmful?
You just pointed on when it would be not(harmful) - "when they want to "evolve" the previous state".
Bonus: delays in the execution("concurency" or network), or just lags (cheap phones), makes more clear which way you should use in every case. I mean - state management could be a tricky thing. If not today, then yesterday.