Week 11: Offline Support & Sync

1. Detecting Connectivity

npx expo install @react-native-community/netinfo

import { useEffect, useState } from 'react';
import NetInfo from '@react-native-community/netinfo';

export function useIsOnline() {
  const [isOnline, setIsOnline] = useState(true);

  useEffect(() => {
    const unsubscribe = NetInfo.addEventListener((state) => {
      setIsOnline(Boolean(state.isConnected && state.isInternetReachable));
    });
    return unsubscribe;
  }, []);

  return isOnline;
}

isConnected means the device has a network interface up (Wi-Fi or cellular); isInternetReachable means that connection actually reaches the internet — a phone connected to a Wi-Fi network with no internet access reports isConnected: true but isInternetReachable: false.

2. Queueing Mutations While Offline

Rather than letting a failed request vanish, write it to a small persisted queue (SQLite, from Week 9, is a natural fit) and attempt it immediately only if online.

type QueuedMutation = { id: string; type: 'createPost'; payload: unknown };

export async function enqueueMutation(mutation: QueuedMutation) {
  db.runSync(
    'INSERT INTO sync_queue (id, type, payload) VALUES (?, ?, ?);',
    [mutation.id, mutation.type, JSON.stringify(mutation.payload)]
  );
}

export async function trySubmit(mutation: QueuedMutation, isOnline: boolean) {
  await enqueueMutation(mutation); // always persist first
  if (isOnline) {
    await flushQueue(); // attempt immediately if we can
  }
}

Persisting before attempting the request means a mutation the user made right as connectivity drops isn't lost — it's already safely queued regardless of whether the immediate attempt succeeds or fails.

3. Syncing on Reconnect

export async function flushQueue() {
  const pending = db.getAllSync('SELECT * FROM sync_queue ORDER BY id ASC;');

  for (const item of pending) {
    try {
      await apiFetch('/posts', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: item.payload,
      });
      db.runSync('DELETE FROM sync_queue WHERE id = ?;', [item.id]);
    } catch {
      break; // stop on first failure, retry the rest next time
    }
  }
}

useEffect(() => {
  return NetInfo.addEventListener((state) => {
    if (state.isConnected && state.isInternetReachable) {
      flushQueue();
    }
  });
}, []);

Processing the queue in order, and stopping on the first failure rather than skipping it, keeps writes applied in the sequence the user made them — important when a later mutation depends on an earlier one having already landed.

4. A Basic Conflict Strategy

Once two devices (or a device and a web client) can both edit the same record while one was offline, they can disagree about its current state. Full conflict resolution is a deep topic; two simple, honest strategies cover most apps starting out:

• Last-write-wins — the server simply accepts whichever update arrives last, timestamped. Simple, occasionally loses a change, acceptable for low-stakes data like a draft note.
• Reject & surface — the server detects the record changed since the client last saw it (a version number or updated_at check) and returns a conflict error the app shows to the user, rather than silently overwriting.

Start with whichever matches how bad it would actually be for a user's change to silently disappear — for a cart, last-write-wins is usually fine; for anything financial, reject-and-surface is the safer default.

5. Hands-on Exercise

6. Knowledge Check

Four quick questions. Expand each to check your answer.