I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
Another approach is to check that the previous process isn't still running inside the setInterval callback and choose whether to skip that iteration or to kill and restart the timer.
Better would be to trigger actions on user events rather than timed events if that's possible, or to use timers only for pure cosmetics. I don't think setInterval/setTimeout are evil as such, as long as you're careful since suddenly everything's in global scope.
There's a temptation to use them to get out of a fix, though, and I think you're definitely right to treat them as a bit of a smell.
Yeah typically I'd expect either a conditional in your response function.
That's also generally how Redux ajax requests are patterned with Redux-Thunk, you would have a conditional in your response handling to verify if it still makes sense to replace the state.
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.
Another approach is to check that the previous process isn't still running inside the setInterval callback and choose whether to skip that iteration or to kill and restart the timer.
Better would be to trigger actions on user events rather than timed events if that's possible, or to use timers only for pure cosmetics. I don't think setInterval/setTimeout are evil as such, as long as you're careful since suddenly everything's in global scope.
There's a temptation to use them to get out of a fix, though, and I think you're definitely right to treat them as a bit of a smell.
Yeah typically I'd expect either a conditional in your response function.
That's also generally how Redux ajax requests are patterned with Redux-Thunk, you would have a conditional in your response handling to verify if it still makes sense to replace the state.