Choosing Between Lodash debounce and throttle for Window Resize Handlers

Decision and constraints

You need to limit calls to a window.resize handler so that it runs no more than once every 200 ms while still receiving the resize event object. The existing code expects the handler to get the event argument, and you cannot change its signature or introduce breaking changes.

Comparison of options

Option	Leading	Trailing	maxWait	Typical use case
_.debounce	configurable	configurable	No	Group rapid calls, invoke after a pause
_.throttle	configurable	configurable	Yes	Ensure steady interval execution
_.debounce {leading:false, trailing:true}	false	true	N/A	Invoke only after the pause (fits the resize case)
_.throttle {leading:true, trailing:false}	true	false	N/A	Invoke immediately then at most every wait ms

Trade‑offs

Debounce with trailing edge reduces total invocations to at most one after the user stops resizing, which can lower CPU usage but delays the final response until the pause ends. Throttle guarantees a regular cadence (e.g., every 200 ms) keeping the UI responsive during continuous resizing, but it may still invoke the handler many times if events fire rapidly.

For a resize handler where you only need the final size, _.debounce with {leading:false, trailing:true} avoids intermediate work while still capturing the last state.

Implementation example

Assuming Lodash 4.x (where the options object is the third argument):

import { debounce } from 'lodash';

function handleResize(e) {
  // e is the native Event object
  console.log('resize', e.target.innerWidth);
}

// 200 ms wait, invoke only on the trailing edge
const debouncedResize = debounce(handleResize, 200, { leading: false, trailing: true });

window.addEventListener('resize', debouncedResize);

Validation

You can verify the behavior without relying on real‑time user interaction:

1. Use a testing framework that supports fake timers (e.g., Jest).
2. Mock the resize event and call the debounced function several times within the wait period.
3. Advance the timer by a period longer than the wait (e.g., 250 ms).
4. Assert that the original handler was invoked exactly once.

jest.useFakeTimers();
[1,2,3,4,5].forEach(() => window.dispatchEvent(new Event('resize')));
jest.advanceTimersByTime(250);
expect(handleResize).toHaveBeenCalledTimes(1);

As a manual check, open the browser console, attach the debounced handler, rapidly resize the window, and confirm that the log appears only after you stop resizing, not during the intermediate steps.

Limitations and practical checks

• Delay: The final resize is processed only after the user pauses for at least the wait time (200 ms). If immediate feedback is required, debounce is unsuitable.
• Version sensitivity: In Lodash 3.x the options object is the second argument; using the wrong version will produce different behavior or errors.
• Wait‑time tuning: A wait longer than ~300 ms may feel laggy for interactive resizing. Profile the actual event frequency and adjust the wait based on user feedback.

To confirm the chosen wait works in your environment, measure the time between the last resize event and the handler execution using performance.now() in a development build.