Users think your app is broken not because the API is slow, but because the UI is rude. I share how I replaced flickering loading screens with Skeleton UI and swapped alert() boxes for graceful Error Boundaries to dramatically improve UX.
Yellow stripes appear when the keyboard pops up? Learn how to handle layout overflows using resizeToAvoidBottomInset, SingleChildScrollView, and tricks for chat apps.
Tired of naming classes? Writing CSS directly inside HTML sounds ugly, but it became the world standard. Why?
Class is there, but style is missing? Debugging Tailwind CSS like a detective.
For visually impaired, for keyboard users, and for your future self. Small `alt` tag makes a big difference.
Before diving into code, let's talk about why we should obsess over loading states. There is a famous study by Amazon. "Every 100ms latency costs 1% in sales." Conversely, designing a good loading screen can significantly reduce bounce rates. Reducing physical API latency is hard (physics), but reducing psychological wait time is possible through design.
That's what my friend said when he saw the early version of my app. "It works, but... it feels cheap. Every time I click, the screen flashes and content jumps around."
The cause was the so-called 'Layout Shift'.
I showed nothing (return null) while fetching data, then suddenly rendered the screen when data arrived.
/* Bad Example */
if (loading) return null; // White screen during loading
if (error) return <div>Error!</div>;
return <Content data={data} />;
This 0.5-second white screen made users anxious ("Did it freeze?"), and the sudden content pop-in caused eye strain.
Have you ever tried to click a 'Cancel' button, but an ad popped up and you accidentally clicked 'Buy'?
Google calls this CLS (Cumulative Layout Shift).
It's a major factor in Core Web Vitals that kills your SEO score.
Google considers this "Deceptive UI", not just "Ugly UI".
It happens when images without defined height push content down after loading.
Open YouTube or Facebook. Instead of a spinning circle, you see gray boxes (bones) first. This is Skeleton UI.
I adopted react-loading-skeleton and replaced all loading screens.
/* Good Example */
if (loading) {
return (
<div className="card">
<Skeleton height={200} /> {/* Image placeholder */}
<Skeleton count={3} /> {/* 3 lines of text placeholder */}
</div>
);
}
The result was amazing. The API speed was the same, but users felt "The app became much faster." Because the brain anticipates "Ah, an image will appear there," the wait feels shorter.
Lesson: Performance optimization includes increasing 'Perceived Performance' too.
Not all skeletons are created equal. Here are 3 rules:
A bigger problem was error handling. When APIs failed, I lazily did this:
.catch(err => alert("Server Error Occurred."))
This is the worst for UX. A warning pops up, and when they click OK, the screen stays white or unresponsive. "So what? Should I refresh? Reinstall the app?"
I introduced Error Bundle and Graceful Degradation.
If one photo in an Instagram feed fails to load, the whole app shouldn't crash. Show a "Failed to load image [Retry]" button for that part only, and show the rest normally.
/* The Majesty of React Query */
if (isError) {
return (
<div className="error-box">
<p>Failed to load data.</p>
<button onClick={() => refetch()}>Retry</button>
</div>
);
}
Isolating the "Failed Part" from the "Alive Part" stopped users from thinking the app was 'broken'.
Standard try-catch often misses errors in async code or event handlers because they run outside React's render lifecycle.
I highly recommend react-error-boundary.
import { ErrorBoundary } from 'react-error-boundary';
function App() {
return (
<ErrorBoundary
FallbackComponent={ErrorFallback}
onReset={() => {
// Reset state on retry (e.g., refetch query)
resetQueries();
}}
>
<MyComponent />
</ErrorBoundary>
);
}
It allows Declarative Error Handling, making your code much cleaner than scattered try-catch blocks.
Ever clicked a "Like" button multiple times because it was slow?
We usually disabled the button during loading to prevent this.
But a better way is Optimistic UI. Believing "The server will succeed," we update the UI number by +1 immediately.
This gives instant responsiveness, like the app is glued to your finger. (Of course, don't use this for payments. Double billing is a disaster.)
With React 18, defensive code like return null or if (loading) is becoming obsolete.
<Suspense> automatically detects loading states and shows the skeleton.
/* Before: Imperative */
if (loading) return <Skeleton />;
return <Data />;
/* After: Declarative */
<Suspense fallback={<Skeleton />}>
<DataComponent />
</Suspense>
This is the future of modern frontend. Focusing on "What" to show, not "How" to load it.
Developers spend less time staring at loading bars than users. (Localhost is fast.) But users use our apps on unstable Wi-Fi and slow LTE.
Just following these three rules will make your app look less like "Homework" and more like a "Product". Even the waiting time is part of your service.
According to David Maister's "The Psychology of Waiting Lines":
Unoccupied time feels longer than occupied time. This is why Skeleton UI works. It gives the eye something to scan, "occupying" the user's attention. A white screen is "unoccupied time".
Unexplained waits are longer than explained waits. If a spinner spins for 10 seconds without text, users panic. "Is it broken?" Adding a text "Creating your report..." explains the wait and reduces abandonment.
Anxiety makes waits seem longer. The uncertainty of "Did my click register?" causes anxiety. Immediate feedback (Ripple effect, Active state) removes this anxiety instantly.
font-display: swap to prevent invisible text (FOIT)?loading="lazy")Tick these boxes, and your app is already in the top 1%.