In this video, let's demystify two important concepts in JavaScript development. That is debouncing and throttling. On the screen, you'll see a mouse area over here where we can move our mouse. The top bar records the mouse events that occur just as they normally would.
So every time I move my mouse, we get all of these different events fired. In the next row here though, we see what debouncing does to that event. Notice that the debounced event, the debounced mouse move, only fires a single time. That is when I actually stop moving my mouse.
So this is how debounce works. It listens for an event, but then it actually only fires when you're done with the event fully. Or you've reached a specific amount of time that the event is no longer occurring. So if I move my mouse again, pause for a moment, and then move again, you'll see that we do have a few debounced lines.
Debouncing is perfect for search input fields, where you want to wait for a user to stop typing before you actually make a request to your API. It's great for window resize handlers and also saving drafts as someone is typing. But what about throttling? You'll see that it works a little bit differently here.
Notice that it's still tracking our movement, but only at regular intervals, like taking a snapshot every 100 milliseconds. You can think of throttling like a speed limit for your function calls. No matter how fast you move the mouse, it will always fire at a steady rate. Throttling is perfect for scenarios like handling scroll events, processing game loop updates, or tracking real-time progress.
Enough theory though, let's take a look at a realistic scenario where we can benefit from debouncing. view over in my view application, we have some dummy data being displayed to the page down here. They are products. This is the result of that over in the browser.
com. and we're passing in a query value in order to search for specific products. This query variable is tied to the input that is above all of the products here. That way, whenever query changes, we refetch the products.
Over in the browser, let's open up the network tab and see what things look like when we search for a new product. How about we look for dog food? Okay. we do get a nice result on the page.
But in the network tab, take a look at all the unnecessary requests. We've made requests for literally every single keystroke that the user types. This is hammering our server unnecessarily. Now imagine if lots of users were doing this at the same time.
The backend team certainly wouldn't be happy. An easy way to remedy this while still getting the nice responsive feedback from our search input without having to hit some kind of button is to simply debounce our query. So instead of watching the query for changes, we'll use the watch debounced function from view use. Watch debounce works exactly like watch.
It takes in the reactive variable to watch. a callback function to run whenever that variable changes, but then it takes a third options object where we can specify a debounce timeout. What this says is wait for the user to pause their typing for half a second and only then rerun the search products function. This time, if we open up our network tab, clear things out, and search for dog food again, Notice that the request is only made a single time, once I've completely typed out dog food.
And the response that the user gets is still nice and snappy. This is the perfect use case for debouncing, and I use it literally all the time. Now let's take a quick look at debouncing within a Nuxt application. This is the exact same setup.
It's just written using Nuxt's useFetch function. but it displays the exact same products to the page with a search input to search through them. Since Nuxt will automatically rerun this request whenever the URL changes, instead of using washed debounce, we can use ref-debounce from Vue. It takes a reactive ref as its first argument, and then the second argument is the debounce timeout.
In this case, we'll do half a second just like before. The result is a debounced version of the reactive variable. So whenever query changes, the bounced query will update, but only after the 500 millisecond timeout. And if query changes before that 500 millisecond timeout is reached, the timer will start all over again, essentially achieving the exact same thing that we did on the last page.
So now let's add a debounced query here. as a dependency of our URL, meaning that the fetch request will only rerun when debounced query changes. I'll save that and then over in my next application, let's try searching for dog food again. But first, let me open up the network tab here so that we can see the fetch request.
Perfect, works exactly the same. So reaching for ref debounced and watch debounced, can prevent hammering your API servers, causing suboptimal response times. Note that Vue use does also have a watch throttled and a ref throttled function, but I don't reach for them nearly as often as the debouncing functions. Have you?
Let us know in the comments below what you typically use throttled for.