How do you approach Frontend: useDebounce Hook (Trailing Edge Behavior)?

Walk events: each event 'survives' iff the next event's time is more than delay after this event's time, OR it's the last event.

What are common mistakes on Frontend: useDebounce Hook (Trailing Edge Behavior)?

An incomplete dependency array, which pins the effect to a stale closure. Mutating state in place instead of replacing it, so no re-render is scheduled. Never cleaning up the timer, listener or subscription on unmount.

gitGood.dev

← Back to problems

Frontend: useDebounce Hook (Trailing Edge Behavior)

MediumTypeScript

Description

This problem is paper-only - see explanation for the canonical React solution.

A debounce drops fast-firing events and only emits after delay ms of silence. The auto-grader validates the timing decision: given an array of { value, time } events and a delay, return the array of (value, emitTime) pairs that a trailing-edge debounce would emit.

Trailing-edge rule: an event "wins" iff no other event arrives within delay ms after it. Its emit time is event.time + delay.

For the auto-grader: implement debounceEmissions(events, delay) returning [{ value, emitTime }] in order.

Example 1

Input: events = [{value:"a",time:0},{value:"b",time:10},{value:"c",time:20}], delay = 100

Output: [{value:"c",emitTime:120}]

Explanation: Each event arrives within 100ms of the next, so only the last one survives. Emitted at 20+100.

Example 2

Input: events = [{value:"a",time:0},{value:"b",time:200}], delay = 100

Output: [{value:"a",emitTime:100},{value:"b",emitTime:300}]

Explanation: 200ms gap > 100ms delay, so both fire on their own trailing edge.

Constraints

- 0 <= events.length <= 1000 - events are sorted by time ascending; times are non-negative integers. - 1 <= delay <= 10000

Frontend: useDebounce Hook (Trailing Edge Behavior): approach, complexity and pitfalls

A medium frontend problem, graded against 5 test cases (3 of them hidden).

The pattern: Frontend

React and browser-platform problems - hooks, event handling, and rendering behaviour.

Reach for it when you see: A component, hook, or DOM-behaviour question rather than an algorithm.

If you are stuck

Show the 1-step hint ladder

Walk events: each event 'survives' iff the next event's time is more than `delay` after this event's time, OR it's the last event.

The optimal approach

Show the approach: Canonical React hook:

```tsx

export function useDebounce<T>(value: T, delay: number): T {

const [debounced, setDebounced] = useState(value);

useEffect(() => {

const handle = setTimeout(() => setDebounced(value), delay);

return () => clearTimeout(handle);

}, [value, delay]);

return debounced;

}

```

Why this works: every change to `value` schedules a new timeout AND cancels the previous one (in the cleanup). Only the last value before a quiet period of `delay` ms survives to be set into `debounced`. The trailing-edge model.

Variants worth knowing:

- Leading edge: fire immediately, then ignore for `delay` ms. Useful for "submit" buttons (prevent double-clicks).

- Both edges: fire immediately AND on the trailing edge.

- maxWait: force a flush after `maxWait` ms even if events keep coming - prevents indefinite starvation. Lodash `debounce` supports all of these.

Throttle vs debounce: throttle limits to N calls per second (drop excess); debounce waits for silence before firing. Pick based on UX: scroll handlers want throttle, search inputs want debounce.

The full reference solution in every supported language stays in the editor above - reveal it there once you have had a real attempt.

What the tests check

Read off this problem's own test suite, so these are the cases a submission actually has to survive.

Empty input. At least one case passes an empty collection. Make sure your loop bounds and any "first element" read survive a length of zero.
Single element. A one-element case is included. Two-pointer and window solutions frequently return the wrong thing when the two indices start out equal.

Common Frontend mistakes

These apply to the pattern as a whole, not just this problem.

An incomplete dependency array, which pins the effect to a stale closure.
Mutating state in place instead of replacing it, so no re-render is scheduled.
Never cleaning up the timer, listener or subscription on unmount.