TanStack Pacer provides five strategies for controlling when operations run. The right choice depends on what should happen to calls that arrive faster than your application can process them.
| Utility | What happens to frequent calls? | Best fit |
|---|---|---|
| Debouncer | Earlier calls are discarded. The latest call runs after activity stops. | Search input, validation, autosave |
| Throttler | Calls are limited to a steady interval. A trailing call can retain the latest arguments. | Scroll, resize, progress, repeated UI updates |
| Rate Limiter | Calls run until a quota is reached. Additional calls are rejected until capacity returns. | Client-side quotas and burst limits |
| Queuer | Calls wait in an ordered buffer and run individually. | Work that must not be lost |
| Batcher | Items accumulate and run together as one batch. | Bulk requests, writes, and analytics events |
Use a debouncer. Every call restarts a timer, and the most recent call runs after the activity becomes quiet.
Use a throttler. It limits execution frequency without waiting for activity to stop completely.
Use a rate limiter. It accepts calls until the configured limit is reached, then rejects additional calls within the window.
Use a queuer. It preserves pending operations and processes them according to FIFO, LIFO, or priority ordering. A finite maxSize can still cause new items to be rejected.
Use a batcher. It collects items until a size, time, or custom condition triggers one batch execution.
Each utility has a synchronous and asynchronous version. Start with the synchronous version unless the utility must manage Promise-specific behavior.
Use the asynchronous version when you need to:
Passing an async function to a synchronous utility does not provide these features. The synchronous utility invokes the function but does not await or manage its Promise.
| Synchronous | Asynchronous |
|---|---|
| Debouncing | Async debouncing |
| Throttling | Async throttling |
| Rate limiting | Async rate limiting |
| Queuing | Async queuing |
| Batching | Async batching |
The async utilities use AsyncRetryer internally for retry and abort support.
Use @tanstack/pacer when you need the core classes and functions without component lifecycle integration.
Use a framework adapter in an application that needs automatic cleanup and reactive state:
Framework adapters provide several API shapes around the same underlying utility:
Choose the narrowest API that provides the control you need. Use the instance API when you need methods such as cancel() or flush().
@tanstack/pacer-lite is intended for libraries that need smaller, non-reactive utilities. It omits TanStack Store integration, framework adapters, Devtools support, and some advanced options.
Use the regular core package or a framework adapter for application code. Consider Pacer Lite when bundle size is the primary constraint and reactive state is unnecessary.