The simplest throttle compares the current timestamp against the last accepted call. If at least wait milliseconds have passed, the new call goes through and the timestamp resets; otherwise it is silently dropped. This pattern fires on the leading edge (the very first call always wins) which feels responsive for analytics beacons and event logging. The downside is that if a burst of calls all land inside one window, only the first sees the latest arguments, so the trailing data is lost. Pair this with a debounce on the trailing edge if both are needed (see the Hard accordion js-throttle-leading-trailing).

Switching to setTimeout gives you two useful properties. The fire is scheduled exactly wait milliseconds after the first call in a burst, so the gap between fires is constant and predictable. And because lastArgs is rewritten on every call, the deferred fire always uses the most recent arguments, which is what scroll-position trackers actually want. The cost is that the very first call no longer fires immediately; if you need leading-edge behaviour, set scheduled = false AND call fn once in the same branch the first time.

Cancellation is the same story as for debounce: a route change or component unmount needs to drop the pending fire so the analytics beacon does not run with stale state. The implementation closes over timer and lastArgs and clears both when cancel is called. This pattern composes well with the React effect cleanup contract: return throttled.cancel from your useEffect and the throttled handler will not fire after the component unmounts. Use this version inside framework-managed lifecycles where teardown is not optional.