re: React's bogus setState anti-pattern VIEW POST

TOP OF THREAD FULL DISCUSSION
re: 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 th...

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.

code of conduct - report abuse