Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
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)?
-
@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
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).
Jason(JSON)
rant