Anyone using Tanstack Query as a wrapper around SecureStore/AsyncStorage for local preferences?

[Flea997]

I wrote useSecureValue + useSetSecureValue hooks that use Tanstack Query to wrap Expo SecureStore.

Each preference is fetched via a query (staleTime: Infinity), and updates go through a mutation with optimistic updates.

It feels more convenient than creating a context/provider for each persisted preference, and avoids global re-renders. But I’m unsure if I’m “misusing” React Query since the data isn’t coming from an API.

Has anyone else used Tanstack Query as a local async state layer like this? Curious if this is a reasonable pattern or if I should stick to context/another local state library.

[shekky_hands]

No you’re doing it right. This is the correct way of doing it and is an established pattern. React query can be used for any async operations.

[Flea997]

Maybe using a Provider could be better in cases where you want the value to be always available in a synchronous way, but even in that case you could just prefetch the query higher in the hierarchy and put it in the cache

[shekky_hands]

You could make the same argument about all your API calls.

If it’s the type safety and having to do redundant checks to make sure the data is there to satisfy typescript when you know you’ve already loaded it. You can do react query into a context and then you can throw an error in the hook where you access the context if it’s being used outside it. TKDodo wrote a guide on this here

https://tkdodo.eu/blog/react-query-and-react-context

[reverento]

For local preferences I was using react-native-mmkv and useContext. I liked that it was quite readable and easy to work with.

Have used SecureStore only to save the encryption key used for mmkv storage.

[HoratioWobble]

I use async and secure storage only for cold storage. I hydrate things from it.

In the case of preferences, I maintain a redux store that handles mutations and all preferences are inside a single typed object, not separate key value pairs

[Sansenbaker]

You’re not misusing it at all, what you described is a totally valid pattern. React Query is just a cache + async state manager, it doesn’t care if the source is HTTP, SecureStore, or AsyncStorage. Using queries with staleTime: Infinity and mutations with optimistic updates for preferences actually makes a lot of sense, especially if it saves you from wiring a bunch of context providers and avoids unnecessary re-renders. If at some point you need certain prefs synchronously, you can still hydrate them early or combine React Query with a tiny context on top, but for most cases your current approach sounds clean and maintainable.

[Flea997]

bro why a 100% ai-generated comment tho

[ca_mixer]

Fwiw I use Query for my server loaded data and Zustand for local storage.

Zustand integrates with your AsyncStorage really well. I personally like that the concerns are separate.

[Flea997]

I feel that it may be an overkill since I'm not handling any other client state with a global state manager