Listener in tempo reale e persistenza offline

Firestore offers two ways to read data: one-time reads with .get() and real-time listeners with .onSnapshot(). A real-time listener keeps a persistent connection open and fires your callback every time the document or query result changes, including the initial data load.

Use .get() when you only need data once (like loading user settings on app start). Use .onSnapshot() when data changes frequently and the UI must stay up to date, like a chat feed or a live score.

Call .onSnapshot(callback) on a DocumentReference to listen for changes to a specific document. The callback fires immediately with the current data and again whenever the document changes.

.onSnapshot() returns an unsubscribe function. Store it in a variable and call it in your useEffect cleanup to stop the listener when the component unmounts and avoid memory leaks.

Attach .onSnapshot() to a collection query to receive live updates whenever any document in the result set is added, modified, or removed. The QuerySnapshot passed to the callback contains all matching documents — not just the changed ones.

This means each time a document changes, you rebuild the entire list from snapshot.docs. This is fine for small to medium lists, and Firestore's local cache makes it fast even without a network round-trip for cached data.

Instead of rebuilding the entire list on every snapshot, you can inspect the changes array to see exactly what was added, modified, or removed. Each entry in snapshot.docChanges() has a type property: 'added', 'modified', or 'removed'.

This approach is more efficient for large collections where only a few documents change at a time. You surgically update the local state array instead of replacing it entirely.

.onSnapshot() accepts a second argument for error handling. When the listener fails — typically due to a permission error from Firestore Security Rules — the error callback fires with a FirebaseError.

Common error codes include permission-denied (security rules blocked the read) and unavailable (offline and no cached data). Always provide an error handler so you can display a fallback UI instead of silently failing.

React Native Firebase enables offline persistence by default on mobile. This means Firestore caches all documents you read or listen to in a local SQLite database on the device. When the device has no internet, reads return cached data immediately.

You do not need any configuration to enable this — it just works. You can control the cache size limit (default 40 MB). When the cache is full, Firestore evicts the least recently used documents. You can also set it to unlimited with cacheSizeBytes: firestore.CACHE_SIZE_UNLIMITED.

By default, .get() tries the server first and falls back to the cache if offline. You can override this by specifying a source option: { source: 'cache' } always reads from local cache (instant, no network) and { source: 'server' } always goes to the network.

Cache-only reads are useful for optimistic UI patterns where you want to render existing data immediately while a fresh network request is in progress. If the document is not in the cache, a cache-only read throws an error.

For large collections, load data in pages using query cursors: .startAfter(lastDocument). You keep a reference to the last document you loaded and pass it to the next query to get the next page. This is known as cursor-based pagination.

Store the last document snapshot in state. When the user scrolls to the bottom of the list (FlatList's onEndReached), trigger a new query starting after the last document. Append the new results to the existing list.

When you combine .where() and .orderBy() on different fields, Firestore requires a composite index. Without it, the query throws a failed-precondition error with a URL to create the index automatically.

Composite indexes are configured in firestore.indexes.json and deployed with the Firebase CLI. During development, just click the URL from the error log — Firebase creates the index for you. For production, always manage indexes in code so they are version controlled.

Real-time listeners consume bandwidth and battery. Detach them when the user navigates away from a screen by using React Navigation's useFocusEffect hook instead of useEffect. useFocusEffect runs the effect when the screen comes into focus and cleans up when the screen loses focus.

This way, you only maintain an active Firestore listener when the relevant screen is visible, and the listener is paused (and re-established) as the user navigates away and back.

For a snappy user experience, apply changes to local state immediately before the Firestore write completes — this is called an optimistic update. Show the change right away, then let the real-time listener confirm or correct it when the server response arrives.

For example, when the user likes a post, increment the like count in local state immediately. If the server write fails, revert the local state by decrementing the count and showing an error toast. This avoids perceived lag on slow connections.

In this lesson you learned: how to attach real-time listeners with .onSnapshot() for live data updates, how Firestore offline persistence automatically caches data for offline use, and how to paginate large collections using startAfter cursor-based pagination. Next up we profile React Native apps and eliminate performance bottlenecks.