-
Notifications
You must be signed in to change notification settings - Fork 408
Do I need a state management tool? #468
-
I have lots of pages and each one listens to useFirestoreCollection, here is a sample:
const customerCollection = collection(firestore, "AllCustomers"); const { data: customersCollection } = useFirestoreCollectionData(customerCollection); const [customers, setCustomers] = useState([]); useEffect(() => { setCustomers([]); const data = []; customersCollection.forEach((customersArr) => { customersArr.customers.forEach((customer) => { data.push(customer); }); }); setCustomers(data); }, []);
It works okay, but I am wondering what happens when a user re-visits the component and make it re-render. Does the app sends a read call to firestore each time the component re-renders? The persistence is enabled so I'm guessing it does not.
Is it okay to write this kind of code for other collections at the top of each page and send the data through props?
Are there any performance penalties between using this and using this with a state management tool?
If this should be used with a state management tool, which one works best? Should I use redux toolkit or Valtio or just Context API?
Concurrent mode is enabled, so things work really easily.
Beta Was this translation helpful? Give feedback.
All reactions
Hi @adamfarmer0, thanks for your question. The main reason to use a state management tool would be if you have very complex app state outside of Firebase. In terms of just fetching some data from Firestore and rendering it, no state library is needed. Take a look at the ReactFire docs to see how to render a list of data from Firestore.
To answer your specific questions:
Does the app sends a read call to firestore each time the component re-renders?
No, reads shouldn't be re-issued. ReactFire caches the active Firestore listeners, so as long as your query doesn't change, it will keep the active listener open instead of creating a new one.
Is it okay to write this kind of code for other ...
Replies: 1 comment 4 replies
-
Hi @adamfarmer0, thanks for your question. The main reason to use a state management tool would be if you have very complex app state outside of Firebase. In terms of just fetching some data from Firestore and rendering it, no state library is needed. Take a look at the ReactFire docs to see how to render a list of data from Firestore.
To answer your specific questions:
Does the app sends a read call to firestore each time the component re-renders?
No, reads shouldn't be re-issued. ReactFire caches the active Firestore listeners, so as long as your query doesn't change, it will keep the active listener open instead of creating a new one.
Is it okay to write this kind of code for other collections at the top of each page and send the data through props?
Sure, once you get data back from ReactFire, treat it like any other object/array/string/value in JavaScript.
Are there any performance penalties between using this and using this with a state management tool?
None besides the overhead of using any state management tool.
Beta Was this translation helpful? Give feedback.
All reactions
-
Thanks, I think that way the app would be simple and easier to maintain, I might need context api here and there but I guess that would be rare. I am new to react so this really clears some confusion and now I can code with an ease of mind.
Beta Was this translation helpful? Give feedback.
All reactions
-
Glad to hear it :)
Beta Was this translation helpful? Give feedback.
All reactions
-
Hi @jhuleatt,
Just want to make sure this also happens in my use case.
If I have a parent component and a child component that both render the same useFirestoreCollectionData query, does it read it twice?
Beta Was this translation helpful? Give feedback.
All reactions
-
Hi @MichaelVidStep, it will read once. If you notice it doing otherwise, please file an issue.
Beta Was this translation helpful? Give feedback.