What belongs in the cache

raf-query is a cache for asynchronous data: anything you load with a promise, that can go out of date, and that many components may need. Most of that is data a backend owns — posts, users, comments. It also fits work only the browser can do: a push subscription, a notification permission, a service worker. Their handles are built in the browser after hydration, so they never run during SSR, and they use the same factories, handles, invalidation and readers as everything else.

It's not a general-purpose state manager for synchronous UI state.

Once async data lives in the cache, most apps find that what's left is small:

State	Where it belongs
Posts, users, comments, anything from a backend	raf-query
Push subscription, permission, service worker, media query	raf-query, browser-only
Filters, sort, pagination, the selected tab	The URL: search params and the path
An input's text, whether a menu is open	useState in the component
Pending and optimistic state of a write	useActionState, useOptimistic
Theme, a draft that survives navigation	A small client store, or localStorage

The URL deserves special mention. raf-query asks that anything which changes what a query fetches lives in the URL, so the loader can start the query on navigation. That's also what makes a page shareable, bookmarkable and restorable with the back button, which state in a store isn't.

Copying query data into a store

Avoid copying query data into a client store (or into useState). The copy doesn't refetch, doesn't hear about invalidation, and goes stale the moment the cache updates. Read the query wherever the data is needed: requests are deduped, and readers share one cache entry.

The exception is a form: initializing an input from query data is fine. defaultValue={post.title} gives the user their own copy to edit, and the write goes through an action.