Offline access to Firestore sub-collections

Question

Looking for advice on my data structure in Firebase.

My app: Plant care reminders

I'm thinking the basic data structure can look something like this.

So the user can have many plants, and for each plant it can have many tasks.

I believe I would have a collection of users top level in Firestore, then each userData document would have a sub-collection of plants. Subsequently each plant would have a sub-collection of tasks.

The app will display all the users plants on one screen, that user can then click on a plant and view the tasks.

---

I would like the ability for the user to go offline for a period and still be able to access everything.

Is it wise to do one big query to retrieve all the data on the app load up? Doing this to make sure if they do go offline Firestore has all their cached sub-collections.

Or is it better to do a query on load up to get the users sub-collection of plants so they can see what they have, then when they click on a plant do another query to get that plants sub-collection of tasks?

If a user can see a plant, then goes offline and clicks that plant. Is it possible to query the plants sub-collection of tasks without network connection?

---

Apologies for poor explanation, trying to wrap my head round offline data persistence with Firestore and nested sub-collections when Firestore does shallow queries.

Answer 1

Firestore's disk persistence functions as a cache, maintaining data the app has recently loaded, and all local write operations that haven't been synchronized to the server yet.

I would like the ability for the user to go offline for a period and still be able to access everything.

This is inherently not a great match for how the Firestore disk cache works. To make it work in your use-case, you'd need to make sure to read all data, which will both drive up read operations and bandwidth consumption, and will also make the local cache runs more slowly than needed.

If you need a fully local database instead of a cache of recently read and locally modified data, Firestore might not be the best fit for this use-case. Consider using your own local database instead.