Weather Dashboard App

Build a weather dashboard with city search, forecasts, and saved recent searches

HTML
CSS
Responsive UI
JavaScript
Fetch API
Async / Await
Local Storage

In this project, you will build a weather dashboard that lets users search by city and instantly see current conditions plus a short forecast. The UI must include a search input, a clear “current weather” panel, and a forecast section that displays multiple upcoming time blocks or days with temperature and conditions. Your app must handle loading, empty states, and “city not found” errors without breaking the layout.

Every successful search must be stored in localStorage and displayed as a recent-search list that users can click to reload weather data for that city. The list should update in real time, avoid duplicates, and keep a sensible limit. The dashboard must remain readable on mobile and desktop, with consistent spacing and predictable content formatting.

What This App Teaches in a Real Workflow

This project trains the full frontend loop: accept input, fetch data, transform it into UI-friendly output, and store user history for a better experience. You will practice building stable request logic, rendering conditional states, and keeping the interface consistent while data changes.

Weather dashboards reflect a common product pattern: search-driven pages with API responses and persistent user preferences. Completing this task shows that you can deliver a practical interface that behaves reliably across refreshes and repeated use.

Baseline Skills Required

You should already write basic HTML/CSS layouts and feel comfortable with JavaScript functions and events. This project assumes you can call an API endpoint, read JSON, and update the DOM without frameworks.

HTML forms and input handling
CSS layout fundamentals and responsive spacing
JavaScript events (submit, click) and DOM updates
Fetch API with async/await and error handling
Working with localStorage and JSON serialization
Basic data formatting (units, dates, labels)

Acceptance Criteria for a Production-Style Dashboard

A credible dashboard focuses on correctness and user trust: searches return the right city, the forecast stays readable, and the app communicates errors without confusion. These requirements mirror how entry-level frontend work is evaluated - state handling, predictable UI updates, and persistence that survives refreshes.

Requirement	Explanation
City search with input validation	Validation prevents wasted requests and keeps UI feedback clean when input is empty or invalid.
Current weather panel	A clear current-state section organizes key data and sets the baseline for the rest of the dashboard.
Forecast section with multiple entries	A structured forecast proves you can map API data into repeatable UI components.
Loading and error states	Reliable messaging builds user trust and prevents “blank UI” confusion during network issues.
Recent searches stored in localStorage	Persistence improves usability and demonstrates practical state storage between sessions.
Clickable recent-search items	Re-running searches from history shows you can connect stored state to new API requests.
Duplicate handling and list limits	A clean history list stays useful and prevents localStorage from turning into noisy clutter.
Responsive layout for mobile	Dashboards must remain readable on small screens, with cards stacking and text staying legible.

Build Tips That Prevent Common Bugs

Treat data handling and UI rendering as separate responsibilities. First, build a request layer that returns a normalized object: city name, current values, and an array of forecast entries. Then render from that model, replacing the UI cleanly on each search. For recent searches, store a small list and update it only after successful responses to keep history accurate. When debugging, watch network responses in DevTools and verify that your UI never depends on optional fields. When your data model stays consistent, the interface stays stable.

Use a single render function for forecast items so formatting stays consistent across entries
Show a loading state immediately to prevent repeated submits and “nothing happened” confusion
Store recent searches as an array and always deduplicate before saving
Limit history length (for example 5-10 cities) to keep the UI focused and storage clean

By completing this project, you'll gain practical experience building a search-driven dashboard that fetches live weather data, renders current conditions and forecasts, and stores recent searches in localStorage for a smoother repeat experience. This foundation strengthens your skills in async UI updates, error handling, data formatting, and persistence - core abilities used in real frontend applications and technical interviews.