Why Your React App Shouldn't Just Show a Blank Screen When the API Fails
A lot of tutorials show you how to fetch data in React. Fewer show you what happens when that fetch fails. I found out the gap between those two things the hard way while building a task manager frontend during my intern
A lot of tutorials show you how to fetch data in React. Fewer show you what happens when that fetch fails. I found out the gap between those two things the hard way while building a task manager frontend during my internship at Valentius Kryptix.
The problem
My first version of the app worked great β as long as the backend was running. The moment I stopped the API to test something else, the screen just went blank. No error, no message, nothing. A user in that situation has no idea if the app is broken, their internet dropped, or they did something wrong.
Three states, not one
The fix was to stop treating "loading" as a single state and start treating every request as having three possible outcomes:
Loading β show a spinner, not a frozen UI
Success β show the data
Failure β show a clear message, with a way to retry
This sounds obvious written out, but it's easy to skip when you're focused on getting the happy path working first. I had to go back and add a Spinner and an ErrorBanner component, then make sure every page that fetches data actually uses them.
Testing the unhappy path on purpose
The way I checked this worked was simple: I turned my backend server off while the frontend was still running, then refreshed the page. If your app still shows something helpful in that moment, you're in decent shape. If it shows a blank white screen, that's worth fixing before you consider a feature done.
Where the failures actually happen
A few spots deserve special attention:
The token expiring mid-session (the API should return 401, and the frontend should catch that specific case)
The very first load of a list, before you know if it's "empty" or "still loading"
Submitting a form that fails validation server-side, not just client-side
What this changed about how I build
I now treat error states as part of the feature, not an afterthought bolted on at the end. It changes the estimate for a "simple" list page slightly, but it's the difference between an app that feels reliable and one that just happens to work when everything goes right.
I wrote a full walkthrough of the project β routes, auth, form validation, and the error-handling pattern in more detail β over on the Valentius Kryptix blog:
Read the full article: https://valentiuskryptix.com/how-to-build-a-task-manager-crud-with-a-rest-api-in-react-frontend/
Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.