API practice
Weather dashboard
A city weather dashboard built to practise data fetching, with loading, empty, and error states treated as part of the design.
- Client: Personal
- Date: January 2025
- Role: Front end + data fetching
- Category: API practice
- Timeline: 1 week
Most weather tutorials stop at “it renders when the request succeeds.” I wanted to build the version that still feels solid when the API is slow, the city doesn’t exist, or the rate limit kicks in — because that’s where a real interface earns trust.
The challenge
The free tier of the API rate-limits aggressively and returns inconsistent shapes for edge cases. Searching “Springfield” gives you a dozen results in different countries, and a typo returns a 404 rather than an empty list.
The approach
I mapped every state the screen could be in before writing the fetch logic: idle, loading, success, empty, and error. Each one got its own layout so the page never jumps between a spinner and a wall of text, and the search box keeps its value after a failed request.
Key details
Skeleton blocks match the size of the real cards so nothing shifts when data lands. Errors are written in plain language with a retry action, and the five-day forecast collapses into a scrollable row on mobile instead of shrinking into unreadable columns.
What I learned
Handling failure well is mostly a layout problem, not a logic problem. Once each state had a designed home, the data-fetching code got noticeably simpler because it no longer tried to do two jobs at once.