How do you approach Frontend: Throttle (Leading Edge, Fixed Window)?

Track lastFireTime. The next event fires iff its time >= lastFireTime + interval (or no event has fired yet).

What are common mistakes on Frontend: Throttle (Leading Edge, Fixed Window)?

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: Throttle (Leading Edge, Fixed Window)

MediumTypeScript

Description

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

Throttle limits a function to at most one call per interval ms. Leading-edge fixed-window: the first call in any interval-length window fires immediately; subsequent calls within that window are dropped.

For the auto-grader: implement throttleEmissions(events, interval). Given events = [{ value, time }] (sorted by time), return the array of values that a leading-edge throttle would let through, with their fire times.

Window logic: the first event always fires. After firing at time t, ignore all events with time < t + interval. The next event with time >= t + interval fires (becomes the new t).

Example 1

Input: events = [{value:"a",time:0},{value:"b",time:50},{value:"c",time:100}], interval = 100

Output: [{value:"a",fireTime:0},{value:"c",fireTime:100}]

Explanation: a fires at 0, b is in the window [0, 100), c fires at 100 (just at the boundary).

Example 2

Input: events = [{value:"x",time:5},{value:"y",time:7},{value:"z",time:9}], interval = 100

Output: [{value:"x",fireTime:5}]

Constraints

- 0 <= events.length <= 1000 - times are non-negative integers, sorted ascending. - interval >= 1

Frontend: Throttle (Leading Edge, Fixed Window): approach, complexity and pitfalls

A medium frontend problem, graded against 5 test cases (2 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

Track lastFireTime. The next event fires iff its time >= lastFireTime + interval (or no event has fired yet).

The optimal approach

Show the approach: Canonical JS leading-edge throttle:

```js

function throttle(fn, interval) {

let lastFire = -Infinity;

return function (...args) {

const now = Date.now();

if (now - lastFire >= interval) {

lastFire = now;

fn.apply(this, args);

}

// else drop

};

}

```

Variants worth knowing:

- Trailing edge: ignore the first call, fire the last call after `interval` of silence (this is debounce, not throttle).

- Leading + trailing: fire immediately AND fire once at the end of the window if any calls were dropped (the lodash default).

- Sliding window vs fixed window: the implementation above is "fixed window from last fire". A sliding-window throttle would maintain a queue.

Throttle vs debounce - the canonical question:

- Throttle: "max N calls per second". Fires steadily during a continuous stream. Good for scroll, mousemove, window-resize - things you want updated periodically.

- Debounce: "wait for silence". Only fires when the input stops. Good for search-as-you-type, autosave, expensive validations.

`requestAnimationFrame` as a throttle for animations: `requestAnimationFrame(fn)` runs once per repaint (~60fps), naturally throttling visual updates. Better than `setTimeout(fn, 16)` because it pauses on backgrounded tabs.

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.