Jason(JSON)

Should probably consider replacing lodash. The js api has caught up for most everything natively, is fluent and also performs better.

For the delta there's tools like ramda and rx which actually perform well.

I know what throttling is - but what is debouncing outside electronics (where it is about getting a single key press to only be recognized as a single key press)?

Mine would be like; "very hot blonde lesbians"
No more space left.

Should have been tagged "joke/meme".

@Oktokolo are you familiar with rx?

Jason must not leave "JSON" in their resume.

@Oktokolo It's kinda the same. A debounce has a set interval and will only trigger when it hasn't been called for that amount of time. For example, if it is set to 1 second, and you call i three times in a row, 0.8 seconds apart it will trigger 1 second after the third call. If you were to call it 3 times, each 1.2 seconds apart, it would trigger each time. For example, you can use it to detect when a scroll has stopped if you get an event on every move. Or in electronics to make sure noise in a signal is one signal :)

@Oktokolo The difference between throttling and debouncing is that throttling limits the handling of events during a fixed time frame while debouncing prevents new events until the old ones have been handled.

Typical debouncing thing in JS would be the event handler for the resize or scroll events which can fire hundreds of times per second, but your redraw is only at 60 Hz anyway.

So you schedule the event for the animation redraw timer (RequestAnimationFrame) and block new events until your already scheduled one has been processed.

An example of missing debouncing is devRant: tap the "Post" button twice, and your comment will appear twice. There should be a debouncing like "don't execute the button handler if the button has already been tapped".

@Fast-Nop much better explanation

Ahahahahahahaha THIS

@Fast-Nop
Oh, double posts is a thing i always tend to prevent by checking inside the create post transaction whether the exact same post already exists.
If yes, it likely is a double-submit (fixable by debouncing) - or some bug on our, the network's, or the client's end prevented the user from seing the confirmation, wich caused the user to just try submitting the content in a reloaded form again (not reliably fixable by debouncing).