Nested likes and dislike from posts
❔Advice✅Resolved
General Convex architecture question:
If I have a list of entities, like posts, and each post has hot counters such as likes, dislikes, or other frequently changing engagement data, what is the best way to model the queries?
For example, one query might return the main post list, while another query returns only the counters / user interaction state for the visible post IDs.
I’m trying to understand the best general pattern between:
returning everything in one query
splitting stable data and hot counters into separate queries
using one query per item for the hot data
My concern is:
if everything is in one query, then frequently changing counters may cause the whole list query to update often
if I use one query per item, I may end up with too many subscriptions
if I split them, I’m not sure whether that is the most idiomatic Convex approach
Since Convex queries are live over websockets and not normal fetches, I want to better understand the tradeoff in terms of:
number of subscriptions
rerunning query functions
rerender behavior on the client
overall recommended architecture
In general, for things like posts + likes/dislikes/comments counts, what pattern do you recommend?
I use ai and give it the source code of usePaginatedQuery
answer is
"I checked the usePaginatedQuery source, and it looks like pagination is managed as multiple page-level queries under one hook, not one giant subscription for the whole loaded list. Each loadMore adds another query with its own cursor, and the hook combines them through useQueries(...).
So if page size is 10, loading 1,000 items is closer to having ~100 page queries/subscriptions than one huge live query.
That means if hot fields like likes/dislikes are included in the paginated result, the reactivity is more page-level than full-list-level. So the tradeoff seems to be less “whole list updates” and more “every loaded page containing hot items becomes reactive.”
"
If I have a list of entities, like posts, and each post has hot counters such as likes, dislikes, or other frequently changing engagement data, what is the best way to model the queries?
For example, one query might return the main post list, while another query returns only the counters / user interaction state for the visible post IDs.
I’m trying to understand the best general pattern between:
returning everything in one query
splitting stable data and hot counters into separate queries
using one query per item for the hot data
My concern is:
if everything is in one query, then frequently changing counters may cause the whole list query to update often
if I use one query per item, I may end up with too many subscriptions
if I split them, I’m not sure whether that is the most idiomatic Convex approach
Since Convex queries are live over websockets and not normal fetches, I want to better understand the tradeoff in terms of:
number of subscriptions
rerunning query functions
rerender behavior on the client
overall recommended architecture
In general, for things like posts + likes/dislikes/comments counts, what pattern do you recommend?
I use ai and give it the source code of usePaginatedQuery
answer is
"I checked the usePaginatedQuery source, and it looks like pagination is managed as multiple page-level queries under one hook, not one giant subscription for the whole loaded list. Each loadMore adds another query with its own cursor, and the hook combines them through useQueries(...).
So if page size is 10, loading 1,000 items is closer to having ~100 page queries/subscriptions than one huge live query.
That means if hot fields like likes/dislikes are included in the paginated result, the reactivity is more page-level than full-list-level. So the tradeoff seems to be less “whole list updates” and more “every loaded page containing hot items becomes reactive.”
"
