Handling Network Errors in React Native
Network errors are normal state, not bugs to silence. In React Native, every fetch should expect flakiness and surface a retry path. The footgun is treating a timeout as permanent failure and wiping optimistic local state.
Why it exists
Mobile networks are not broadband. A React Native app moves through dead zones, low battery modes, and handoffs between WiFi and cellular towers. If you treat a failed fetch as an unhandled exception, your UI crashes or leaves the user staring at an infinite spinner. The goal is to keep the app usable when the network is not.
The mental model
Treat every network call as a message sent across an unreliable bridge. The request, the response, and the error are all possible states of the same operation, not separate concerns. Your component should own a state machine that moves from idle to loading to either success or error. Error is a normal state, not a catastrophe.
How it works
Wrap your API layer in a hook or library that tracks status explicitly. Distinguish error families: a 4xx status means the client sent bad data and retrying is useless; a 5xx status means the server is struggling and a limited retry with exponential backoff is reasonable; a timeout or unreachable host means the device has no route and you should wait for connectivity. Use NetInfo to listen for online status. For mutations, use an optimistic update pattern: show the change immediately, queue the server call, and roll back only if the server explicitly rejects it. Never throw a raw exception into the render path; map errors to user-facing messages and recovery actions.
When to use it
Use explicit error handling for every remote read that blocks content, every write that changes server state, and any background sync that must survive app suspension. It is essential when you build offline-first features or when your users are primarily on cellular connections.
When not to use it
Do not wrap non-critical analytics pings in blocking error UI. Do not retry 4xx errors blindly. Do not use infinite retry loops without backoff, because a fleet of devices retrying simultaneously can overwhelm a recovering server. Avoid synchronous network checks on the JavaScript thread.
One canonical example
Imagine a user submits a comment on a photo. The app immediately renders the comment in the list with a pending indicator. The app calls fetch. If the device enters a tunnel and the request times out, the app keeps the comment visible and shows a small retry button. When NetInfo reports the device is back online, the app automatically resends the request. If the server returns a 500, the app retries twice with a one-second and then a two-second delay. If the server returns a 403, the app removes the optimistic comment and navigates to a login screen. The user never loses their typed text.
Interview question
A mutation request times out after an optimistic update in React Native. According to the network error mental model, how should the app handle the UI state and retry path?
- a.Retry the request in an infinite loop without delay until the device regains connectivity
- b.Throw a raw network exception into the render path to trigger an error boundary
- c.Preserve the optimistic update and surface a user-facing message with a recovery retry actionCorrect
- d.Roll back the optimistic update immediately and treat the timeout as a permanent failure
Why? this is the answer
The card teaches that a timeout is a transient network issue, not a permanent failure, so optimistic state should be preserved and users should get a retry path. Rolling back the update is the exact footgun described, while throwing raw exceptions into the render path and infinite retry loops are both explicitly anti-patterns.
Just read this? Test yourself on what you have been reading.
- #react native
- #networking
- #error handling
- #mobile
- #offline
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on react native — each one lists the topics its interview covers.
See open roles