Calling on all developers with SWR-experience in large scale apps to summarise what they've learned.

[Kilanvl1]

I'm imagining something similar to what Theo did with Stripe Theo's recommendations, only let's get advice from as many people as possible. Here are three things I would love to know how others handle:

The fetcher function

• Official typed fetcher function? const fetcher = (...args) => fetch(...args).then(res => res.json()). This but then properly typed on the docs page.
• Is it recommended in SWR to just have a single global fetcher function that is controlled by the args parameter? For example, what if you want to add headers, change the method to post and add a body? Should you define a new fetcher function or just use the args to adjust? Seems to suggest creating a new fetcher
• Official way to make a reusable request abortable?

Handling a SELECT statement that has many parameters

In a few places in my app, I need to collect information from the user (such as filters, pagination, and an input field), which gets used to create an SQL query on the backend. Is it better in this situation to pass all that information as query parameters or use the trigger function returned by the useSWRMutation hook?

[manimovassagh]

Been using SWR in production across several apps with 50k+ daily users. Here are patterns that held up well.

Fetcher Function

Define a base fetcher for GET requests and create specialized ones when you need different HTTP methods or headers:

const fetcher = async <T>(url: string): Promise<T> => {
  const res = await fetch(url, {
    headers: { Authorization: `Bearer ${getToken()}` },
  });
  if (!res.ok) throw new FetchError(res.status, await res.text());
  return res.json();
};

// Provide globally
<SWRConfig value={{ fetcher }}>{children}</SWRConfig>

For mutations, useSWRMutation with its own fetcher is the right call. Do not try to make a universal fetcher for both GETs and POSTs.

For abort support, the fetcher receives an AbortSignal:

const fetcher = (url: string, { signal }: { signal: AbortSignal }) =>
  fetch(url, { signal }).then((r) => r.json());

Parameterized Queries (Filters, Pagination)

Encode parameters in the SWR key. The cache key IS the query:

function useFilteredData(filters: Filters, page: number) {
  const params = new URLSearchParams({ ...filters, page: String(page), limit: "20" });
  return useSWR<SearchResult>(`/api/items?${params}`);
}

Do NOT use useSWRMutation for read operations with user input. Use useSWR with a dynamic key — it handles caching, deduplication, and revalidation properly. The exception is a genuinely expensive search triggered only on explicit button click.

Other Lessons

• Set errorRetryCount globally — default is unlimited retries which hammers a struggling API. Use errorRetryCount: 3.
• isValidating is for background refresh indicators, isLoading is for initial load.
• mutate with optimistic data + rollbackOnError: true makes UI feel instant.
• Key arrays (useSWR([url, params])) — remember the reference changes every render, serialize to a string or use stable refs.

[Kilanvl1]

Parameterised queries on trigger?

"The exception is a genuinely expensive search triggered only on explicit button click." You say, but in many of my applications this is a standard, not an exception. I often have to GET data from an API endpoint that relies on some filters which the user selects on the frontend. Once the user has configured their filters, they click on a button that executes the query. In this case, I found that neither useSWR nor useSWRMutation was appropriate as useSWR creates a dependency between the filters and the endpoint but I only want to trigger it when the user is ready and useSWRMutation should be for mutations not fetching.

Thanks for the rest, I will defnitely incorporate in my projects!