React+Redux+Sails(Node)离线数据持久化与重连同步问询

Hey there! Let's break down how to implement offline persistence and reconnection sync for your React/Redux + Sails.js app—here's a solid approach that avoids the security concerns of local backend sync:

First, you need reliable ways to tell when the app goes offline or comes back online:

• Use the browser's navigator.onLine API as a quick check, but pair it with Axios interceptors to catch failed requests (since navigator.onLine can sometimes show false positives if the server is down but the network is still up).
• Listen to the online and offline window events to trigger mode switches and sync workflows.

Example code for network listeners:

// Listen for network state changes
window.addEventListener('online', () => {
  console.log('Back online! Starting data sync...');
  syncOfflineQueue();
});

window.addEventListener('offline', () => {
  console.log('Network lost—switching to offline mode.');
});

Instead of storing a full local database (which brings security risks), focus on persisting unsynced actions/requests—this keeps the local storage lean and only holds what needs to be sent to the backend later. Here's how:

• Use an IndexedDB wrapper like localForage (better than localStorage for large/async data) to store a "sync queue" of actions that failed to reach the backend.
• Add a Redux middleware that intercepts actions requiring backend calls. If offline, push the action (and its payload) to the sync queue before updating the frontend state (so users still see their changes immediately).

Example Redux offline middleware:

import localForage from 'localforage';

const offlineSyncMiddleware = store => next => async action => {
  // Check if this action needs backend sync
  const requiresSync = ['CREATE_ITEM', 'UPDATE_ITEM', 'DELETE_ITEM'].includes(action.type);
  
  if (requiresSync && !navigator.onLine) {
    // Add the action to the offline sync queue
    const syncQueue = await localForage.getItem('syncQueue') || [];
    syncQueue.push({
      action,
      timestamp: Date.now(),
      userId: store.getState().auth.userId // Include auth context for later
    });
    await localForage.setItem('syncQueue', syncQueue);
  }

  // Always update the frontend state first for a smooth user experience
  return next(action);
};

When the app detects it's back online, process the sync queue in order to ensure data consistency:

• Fetch the queue from IndexedDB, then loop through each item and send the corresponding request to your Sails backend.
• Handle failures gracefully: if a request fails (e.g., token expired, backend error), leave it in the queue and retry on the next reconnection attempt.
• After a successful sync, remove the item from the queue and update the frontend state if needed (e.g., use the backend's returned data to overwrite local state).

Example sync function:

import axios from 'axios';
import localForage from 'localforage';

async function syncOfflineQueue() {
  const syncQueue = await localForage.getItem('syncQueue') || [];
  if (syncQueue.length === 0) return;

  // Process queue in order to maintain data integrity
  for (const queueItem of [...syncQueue]) {
    try {
      const { action } = queueItem;
      // Map Redux actions to Sails API endpoints
      switch (action.type) {
        case 'CREATE_ITEM':
          await axios.post('/api/items', action.payload, {
            headers: { Authorization: `Bearer ${store.getState().auth.token}` }
          });
          break;
        case 'UPDATE_ITEM':
          await axios.put(`/api/items/${action.payload.id}`, action.payload, {
            headers: { Authorization: `Bearer ${store.getState().auth.token}` }
          });
          break;
        case 'DELETE_ITEM':
          await axios.delete(`/api/items/${action.payload.id}`, {
            headers: { Authorization: `Bearer ${store.getState().auth.token}` }
          });
          break;
      }

      // Remove successfully synced item from queue
      const updatedQueue = syncQueue.filter(item => item !== queueItem);
      await localForage.setItem('syncQueue', updatedQueue);
    } catch (error) {
      console.error(`Failed to sync ${queueItem.action.type}:`, error);
      // Stop processing further items to avoid cascading failures
      break;
    }
  }
}

Since you're worried about local server security, this approach keeps all critical logic on your Sails backend:

• All sync requests go directly to your main Sails server, so your existing policies (auth checks, data validation, permission controls) still apply.
• The frontend only stores temporary action data, not sensitive full-database records.
• Ensure sync requests include valid auth tokens (JWT, session cookies) so the backend can verify the user's identity before processing changes.

• Idempotent APIs: Design your Sails endpoints to be idempotent (e.g., use PUT instead of POST for updates, or add unique request IDs) to prevent duplicate data if sync retries happen.
• Conflict Resolution: If the backend data changed while the app was offline, add logic to handle conflicts (e.g., show a user prompt to choose between local and remote changes, or use last-modified timestamps to resolve automatically).
• Redux State Persistence: Use redux-persist to save your core Redux state to IndexedDB, so users don't lose their offline changes if they refresh the page.

内容的提问来源于stack exchange，提问作者Sebas