React & Query/bandwidth optimization
Just hoping for some clarification on what the best practice would be for what I want to achieve and get a bit more understanding of exactly how the subscriptions work and how to avoid re-reading data off the database too often.
I have a pretty simple table structure of:
- Category
- Topic (contains an id field for the category it belongs to)
- Message (contains an id field for the topic it belongs to)
The goal is to display data for all topics in a category, which means reading from ~ 1000 documents to grab the data required at each level. All of the queries have indexes, but the way I'm currently doing it is generating a massive amount of bandwidth.
Currently --
- a single useQuery is run at the top of the React document.
- this query fetches the selected category data, then performs a search for all topic documents linked to that category id. The list of topic documents is then looped through to get a list of all messages related to that topic id.
- all the fetched data is placed in an object that is then returned by the query.
This lets me get a total count of messages per topic off the bat -- but if I'm reading things right, it also means that the entire query is being re-run whenever data changes (thus blowing out bandwidth). Is that correct?
Would I be better off to break up the structure of the app itself and have each stage of the query run within the component? So:
- Category data (fetch category information + topic list IDs, map through topic IDs and provide that to next component)
- Topic data (use provided topic ID to fetch topic data + get related message IDs, provide message IDs to next component)
- Message data (get + display message data)
Will an approach like that mean that if just a piece of message data changes, only the component that the message has been fetched in will re-run? Or does a change to an item on the message table mean all queries related to the message table reruns?
Will a change to something on the category table just cause the category query to react, or will it all retrigger because they're nested?
What's the best pattern/practice here?
I have a pretty simple table structure of:
- Category
- Topic (contains an id field for the category it belongs to)
- Message (contains an id field for the topic it belongs to)
The goal is to display data for all topics in a category, which means reading from ~ 1000 documents to grab the data required at each level. All of the queries have indexes, but the way I'm currently doing it is generating a massive amount of bandwidth.
Currently --
- a single useQuery is run at the top of the React document.
- this query fetches the selected category data, then performs a search for all topic documents linked to that category id. The list of topic documents is then looped through to get a list of all messages related to that topic id.
- all the fetched data is placed in an object that is then returned by the query.
This lets me get a total count of messages per topic off the bat -- but if I'm reading things right, it also means that the entire query is being re-run whenever data changes (thus blowing out bandwidth). Is that correct?
Would I be better off to break up the structure of the app itself and have each stage of the query run within the component? So:
- Category data (fetch category information + topic list IDs, map through topic IDs and provide that to next component)
- Topic data (use provided topic ID to fetch topic data + get related message IDs, provide message IDs to next component)
- Message data (get + display message data)
Will an approach like that mean that if just a piece of message data changes, only the component that the message has been fetched in will re-run? Or does a change to an item on the message table mean all queries related to the message table reruns?
Will a change to something on the category table just cause the category query to react, or will it all retrigger because they're nested?
What's the best pattern/practice here?
