Symptoms & Diagnosis
When JavaScript applications encounter WiFi drops, the user experience often breaks silently. Without proper handling, users might fill out complex forms only to lose all data upon clicking “Submit.”
The primary symptom is a failed network request. In the browser console, you will typically see ERR_INTERNET_DISCONNECTED or ETIMEDOUT errors. However, the most deceptive scenario is “Liar-fi,” where the device is connected to a router with no actual internet access.
Diagnosis begins with the navigator.onLine property. While useful, it only returns a boolean indicating if the browser is connected to a network, not necessarily the internet. Developers must also monitor the online and offline window events to react in real-time.
Troubleshooting Guide
To effectively handle offline mode, you need a robust detection system. Relying solely on the browser’s status property is rarely enough for production-grade applications.
Real-time Event Listening
Start by implementing event listeners to track changes in connectivity. This allows your UI to update immediately when the signal drops.
// Listen for connectivity changes
window.addEventListener('offline', () => {
console.log('User is offline');
showOfflineNotification();
});
window.addEventListener('online', () => {
console.log('User is back online');
syncPendingData();
});
Connectivity API Reference
Use the following properties to diagnose the connection state within your JavaScript logic:
| Property/Method | Description | Reliability |
|---|---|---|
| navigator.onLine | Returns true if the browser has network access. | Medium |
| navigator.connection | Provides info about the system’s connection type (4g, wifi). | High |
| window.onoffline | Event fired when the connection is lost. | High |
Handling Failed Requests
When a fetch() call fails due to a network error, you should implement a retry mechanism with exponential backoff. This ensures that the application recovers gracefully once the WiFi stabilizes.
Prevention
The best way to handle offline mode is to design your application to be “Offline First.” This involves caching essential assets and storing user input locally before attempting a network sync.
Service Workers
Service Workers act as a proxy between your browser and the network. They can intercept requests and serve cached content even when the user is completely offline, preventing the “Downasaur” page.
Local Storage and IndexedDB
For data persistence during WiFi drops, use IndexedDB. Unlike LocalStorage, it is asynchronous and can handle large amounts of structured data. When the connection returns, you can trigger a background sync to push the saved data to your server.
By combining event listeners, Service Workers, and robust local storage, you ensure your JavaScript application remains functional regardless of the user’s network stability.