The classic example is a data table with a text field that filters/searches the results, pulled from a server.
Let’s say you want the results to update “live” as the user types, without having to click a “search” button. So if the user types “bacon” then she sees all results that contain the word “bacon” in them.
Problem is, if the act of sending the text field input to the server and waiting for the results is relatively slow and blocks the UI from updating, then each key press causes a delay between the search results updating on the screen, and the next letter showing up in the search field.
1. User types “b” and then the app sends “b” to the server, pauses, gets a response of all results with the letter “b”.
2. User types “a”, and the app sends “ba” to the server… pauses… gets results. She types a “c”, the app sends “bac”, etc.
Debouncing, then, means the app waits a short period of time to make sure the user is finished typing before sending the search term.
Usually this means every time the user enters a letter into the search field, the app sets a timer for, say, 500ms. If the user doesn’t enter another letter for 500ms, great - send the search term, wait for the results.
If the user does enter another letter within 500ms, then she must still be typing, so reset the timer back to 500ms and hold off on sending the search term out to the server.