7 Replies
A ConveClient object maintains the query results for the set of queries it is subscribed to, and optimistic udpates are shared between this. A ConvexProvider makes these available to a React element tree.
Descendant components access data using useContext() hooksCool, sounds Redux-y/reducery
Is this the recommended strategy for Convex or does local caching mean each child component uses useQuery() directly?I'm confused about what "this" is, could you say more? The generally recommended strategy is indeed for components to use useQuery directly. Similar to react-query But you can write one component that grabs all your queries if you want. Re: local caching, the level at which query results are cached is the ConvexClient, which is typically used by a single ConvexProvider.
Okay, yeah, I think that answers my question. So if two different children of the ConvexProvider use the exact same query, Convex isn't doing two different network calls under the hood. It's doing 1 network call for the first child, and stores a local cache for the second. -- is that understanding correct?
That's correct. And these two components will be updated in the same react render when the query updates.
That's really cool.
It makes my work easier!
This is real nice for when you're doing client-side joins — not a recommended pattern but one that happens in practice sometimes, ie
useQuery('users') and useQuery('posts) where if these update at different times you might have a foreign key on a user that doesn't exist in posts
really we'd rather you do the join on the server-side, but it's nice not to need to think about different queries being at different logical timestamps
(this is an extension from what you asked about, I'm getting a little off topic)No no, all this helps a lot in how to think about Convex and what it's doing
Both questions were highly related.
I have a somewhat unrelated question about the shape of Documents. Is it best asked here or do you prefer to start a new thread?
A new thread woudl be great, we aspire to turn some of these threads into documentation we're missing 🙂