Lodash Throttle Leading False vs Trailing False

In the Lodash library, _.throttle limits the execution rate of a function over a specified wait period, with both leading and trailing options enabled by default. Setting leading: false prevents the throttled function from firing immediately on the first trigger, deferring execution until the wait period has passed. Conversely, setting trailing: false ensures the function executes immediately on the initial trigger but prevents it from executing once more at the end of the wait period if it was called again during that timeframe.

Default Throttle Behavior

By default, _.throttle(fn, wait, { leading: true, trailing: true }) monitors calls across fixed time windows:

• Leading edge: Invokes the function immediately upon the first trigger.
• Trailing edge: If the function is called one or more times during the wait window, it executes one final time after the wait period elapses.

Behavior with { leading: false }

When configured with { leading: false }, the initial call does not trigger immediate execution. Instead, the timer starts, and the function execution is delayed until the end of the wait window (the trailing edge).

• First call: Does not execute immediately.
• Subsequent calls within the window: Keep the pending execution queued for the end of the window.
• Result: The function only fires after the wait duration has completed.
• Common Use Case: Useful when you want to suppress the initial event and only act after a continuous action has been underway, such as delaying API checks until a user has scrolled or typed for a sustained interval.

Note: You cannot set both leading: false and trailing: false simultaneously, as this would result in the function never executing.

Behavior with { trailing: false }

When configured with { trailing: false }, the behavior shifts exclusively to the start of the throttling window:

• First call: Executes immediately on the leading edge.
• Subsequent calls within the window: Entirely ignored. No execution is scheduled for the end of the window.
• Result: Once the initial execution finishes, the function remains completely inactive until the wait window expires, regardless of how many times it was triggered in the meantime.
• Common Use Case: Useful for UI rate-limiting where immediate responsiveness is required, but deferred actions must be discarded—such as preventing rapid duplicate button clicks or double form submissions.

Summary Comparison