Skip to main content

Prepare and get flow

In v3 the search controller handles prepare and execute automatically. When you call get(), the controller prepares the query if needed and retries a 425 response until results are ready.
For advanced use cases, you can call prepare() directly to cache expensive work before calling get().

Reusing a prepared search across pages

Configure storage when you want the results page to reuse a prepared search ID. The SDK stores the prepared ID by the canonical query and request parameters, then resolves it automatically on the next page.
Await prepare() before navigating so the search_id is written to storage. If navigation happens first, the request is likely cancelled and the results page prepares again, which is correct but slower. On the results page, create sdk.search({ query }) with the same request parameters and call get(). Do not read a search ID from the URL or pass one to get().

Debouncing autocomplete

For search-as-you-type, use autocomplete() and debounce the input in your framework or with createDebounce() from the SDK.
The deprecated suggest() method also debounces, but new integrations should use autocomplete() with their own debounce logic.

Concurrent API calls

Call search.prepare() and autocomplete.get() concurrently for a fast search-as-you-type experience.

Aborting stale requests

Controllers are tied to a single request lifecycle. To abort a previous request (for example, when the shopper types a new character), dispose the old controller and create a new one.

Next steps

Caching

Learn how the SDK caches requests and results.

Performance

Optimize your implementation for speed.