QFrontend Quality · Interview preparation
How should frontend apps handle loading and error states?
Represent loading, empty, success and failure as distinct states instead of hiding errors inside a spinner.
The idea to remember.
Represent loading, empty, success and failure as distinct states instead of hiding errors inside a spinner. Provide a retry action when recovery is possible and preserve useful user input.
01Learn by doing
From first example to real project.
Start with the smallest working idea, examine a more detailed example, then look at a real application pattern. Adapt dependencies, error handling and data models to your project.
Basic: test visible behavior
01 / BEGINNERPrefer what users can see to implementation details.
test('shows a heading', () => {
render(<Questions />);
expect(screen.getByRole('heading', { name: /questions/i })).toBeVisible();
});Intermediate: test asynchronous UI
02 / INTERMEDIATEWait for an accessible result instead of sleeping a fixed interval.
test('loads results', async () => {
render(<SearchPage />);
await user.click(screen.getByRole('button', { name: /search/i }));
expect(await screen.findByText('Results ready')).toBeVisible();
});Real scenario: protect an API route
03 / REAL SCENARIOApply validation and authorization server-side; client checks improve UX only.
app.post('/api/orders', authenticate, async (req, res) => {
if (!isValidOrder(req.body)) return res.status(400).json({ error: 'Invalid order' });
if (!canOrder(req.user, req.body)) return res.status(403).end();
res.json(await createOrder(req.user.id, req.body));
});02Check your understanding
Try it in your own words.
Explain how should frontend apps handle loading and error states without looking at the code. Then modify the intermediate example, describe one trade-off and identify when the real-world pattern fits.
Keep learning here.
Explore more in-depth guides, exercises and related interview questions in this library.
Browse Frontend Quality study guides ↗