Global configuration

SWRVConfig provides shared configuration for every SWRV composable call inside the boundary.

For the full option list, see API. This page focuses on how those options are shared across cache boundaries and app subtrees.

<!-- App.vue -->
<script setup lang="ts">
import { SWRVConfig } from "swrv";

const value = {
  refreshInterval: 3000,
  fetcher: (resource: string, init?: RequestInit) =>
    fetch(resource, init).then((response) => response.json()),
};
</script>

<template>
  <SWRVConfig :value="value">
    <Dashboard />
  </SWRVConfig>
</template>

<!-- Dashboard.vue -->
<script setup lang="ts">
import useSWRV from "swrv";

const { data: events } = useSWRV("/api/events");
const { data: projects } = useSWRV("/api/projects");
const { data: user } = useSWRV("/api/user", { refreshInterval: 0 });
</script>

Inside Dashboard, all three useSWRV calls can reuse the same fetcher. The /api/user request still overrides the shared polling policy locally.

Nesting configurations

Nested SWRVConfig boundaries merge with the parent configuration.

Object configuration example

<template>
  <SWRVConfig :value="{ dedupingInterval: 100, refreshInterval: 100, fallback: { a: 1, b: 1 } }">
    <SWRVConfig :value="{ dedupingInterval: 200, fallback: { a: 2, c: 2 } }">
      <Page />
    </SWRVConfig>
  </SWRVConfig>
</template>

The nested boundary resolves to:

{
  dedupingInterval: 200,
  refreshInterval: 100,
  fallback: { a: 2, b: 1, c: 2 },
}

Primitive values override. Mergeable objects such as fallback are merged.

Functional configuration example

You can also derive the next configuration from the parent:

const value = (parent: ReturnType<typeof useSWRVConfig>["config"]) => ({
  ...parent,
  dedupingInterval: parent.dedupingInterval * 5,
});

This is useful when you want to preserve most of the parent settings but adjust a few values for a local subtree.

Extra APIs

Cache provider

SWRVConfig can also define cache ownership:

• client: provide a full SWRV client
• cache: provide a specific cache instance
• provider: create or extend a cache provider from the parent cache

These options are useful when you need one cache per app, test, or SSR request.

See Cache for provider semantics and Server rendering and hydration for request-scoped SSR usage.

<script setup lang="ts">
import { SWRVConfig, createSWRVClient } from "swrv";

const client = createSWRVClient();
</script>

<template>
  <SWRVConfig :value="{ client }">
    <App />
  </SWRVConfig>
</template>

Access to global configurations

Use useSWRVConfig() inside setup() to access the active scoped helpers:

const { cache, client, config, mutate, preload } = useSWRVConfig();

This is the correct way to reach the active cache boundary. If a custom provider is in use, the scoped mutate returned here stays aligned with that provider.

Nested configurations are extended automatically. If no <SWRVConfig> is used, useSWRVConfig() returns the default root configuration and helpers.

See Mutation and Prefetching for how those scoped helpers are used in practice.

Middleware

Register middleware at the boundary with value.use:

const logger = (useSWRVNext) => (key, fetcher, config) => {
  console.log("swrv key", key);
  return useSWRVNext(key, fetcher, config);
};

<SWRVConfig :value="{ use: [logger] }">
  <App />
</SWRVConfig>

See Middleware for the full middleware model.