Combining SolidJS Store with TanStack Query to handle optimistic UI updates
💙Intermediate
Hey everyone! I'm working on an app and I'd love to get your thoughts on my state management approach.
I'm combining SolidJS Store with TanStack Query to handle optimistic UI updates. Here's my reasoning:
- TanStack Query handles all the server state, caching, and invalidation beautifully
- SolidJS Store gives me the ergonomic nested updates I need for complex local state
My use case involves a large interconnected store (projects, versions, hierarchy, criteria, evaluations, etc.) where entities are deeply nested and frequently updated optimistically.
My current approach:
1. Fetch data with TanStack Query
2. Sync it to a SolidJS Store via createEffect (I know, not ideal...)
3. Optimistic updates go to the Store (love the setStore("users", (u) => u.id === id, "status", "on") syntax)
4. On error, reconcile back from Query cache
5. On success, invalidate and refetch
My concerns:
- The createEffect sync feels clunky
- I'm duplicating state between Query cache and Store
- Wondering if I'm fighting against how these libraries are meant to work
My question:
Is this a reasonable pattern for complex nested state with optimistic updates, or am I overcomplicating things? Would you stick with Query's cache updates only, or is there a better way to get Store's ergonomics?
I'm combining SolidJS Store with TanStack Query to handle optimistic UI updates. Here's my reasoning:
- TanStack Query handles all the server state, caching, and invalidation beautifully
- SolidJS Store gives me the ergonomic nested updates I need for complex local state
My use case involves a large interconnected store (projects, versions, hierarchy, criteria, evaluations, etc.) where entities are deeply nested and frequently updated optimistically.
My current approach:
1. Fetch data with TanStack Query
2. Sync it to a SolidJS Store via createEffect (I know, not ideal...)
3. Optimistic updates go to the Store (love the setStore("users", (u) => u.id === id, "status", "on") syntax)
4. On error, reconcile back from Query cache
5. On success, invalidate and refetch
My concerns:
- The createEffect sync feels clunky
- I'm duplicating state between Query cache and Store
- Wondering if I'm fighting against how these libraries are meant to work
My question:
Is this a reasonable pattern for complex nested state with optimistic updates, or am I overcomplicating things? Would you stick with Query's cache updates only, or is there a better way to get Store's ergonomics?
