To be more concrete - I've seen many examples when developers are using the following code:
In my post I clearly state that:
When replacing the state, use the value overload
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.
Don't try to find examples when deriving a state from a prev state is essential. It is a very powerful, useful and good pattern. And I never said the opposite.
Then I guess that I misunderstood you when you said that:
So - it's not an antipattern, - it's a feature.
My response to you had to do with this statement:
Lets imagine - you have a button, a toggle button, and once you clicked it - you toggle something. So - should toggle show something, or should toggle 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 :)
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... :-)
Don't try to call explicit setState an anti-pattern. There are many use cases when it would be more right to use it.
But I don't. Really, I do not. Please read my post again. I only call it an anti-pattern
if your next state depends on the previous one
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?
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".
When they would not want (CRDT, replication, synchronization, not evolve actions and so on) - it would be unnessesary. Just code not as clear, at it could be.
When it would be harmful? Only in situations when you are evolving from a previous state, while you shall not. But that would be not a code-level bug, but a wrong design decision.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.