🛠️ Weekend Project: Frontend Frameworks & State

What You're Building

You'll build a Weather Dashboard: a small single-page app that lets a user search for a city, see current conditions and a short forecast, and pin a few favorite locations that are remembered between visits. It's deliberately modest in scope but rich in the skills that matter — component composition, state management, asynchronous data, and persistence.

Pick one framework you want to practice. The concepts are identical across all three; only the syntax differs.

The finished feature set is small and testable:

• Search a city by name and show current temperature, conditions, humidity, and wind.
• Show a compact multi-day forecast.
• Save and remove favorite cities; favorites survive a reload.
• Toggle °C / °F, and remember that choice too.
• Handle the boring-but-critical states: loading, empty, and error.

How to Approach It (Polya's Method)

Rather than diving straight into code, borrow a four-step problem-solving loop from mathematician George Pólya. It keeps a weekend build from turning into a weekend of thrashing.

⚠️ Resist the urge to build everything at once. A vertical slice — search box → API call → rendered card — that works end-to-end teaches you more in an hour than a half-finished UI for every feature does in a day.

Design the State First

State management is the real subject of this module, so plan it deliberately. The single most useful question you can ask about any piece of data is: who owns it, and who needs to see it? That answer tells you where it lives.

Here's a reasonable shape for the shared store — notice it holds user choices and the active selection, but the fetched weather is cached separately, keyed by city:

// The shared, persisted slice of state
const appState = {
  favorites: ['London', 'Tokyo'], // saved cities
  unit: 'metric',                 // 'metric' (°C) or 'imperial' (°F)
  activeCity: 'London',           // which city the dashboard shows
};

// Server data is cached separately, keyed by "city:unit"
// so switching units or revisiting a city can reuse a recent result.
const weatherCache = new Map(); // 'London:metric' -> { data, fetchedAt }

The Milestones

Work top to bottom. Each milestone leaves you with something that runs — commit at the end of every one so you always have a working fallback.

Milestone 0 — Scaffold & component tree

Create the project, delete the boilerplate, and stub out empty components so the tree is visible. A workable breakdown:

App
├── SearchBar         (local state: input text)
├── UnitToggle        (reads/writes shared: unit)
├── FavoritesList     (reads shared: favorites; click sets activeCity)
│   └── FavoriteItem
└── WeatherPanel      (reads shared: activeCity, unit; fetches server data)
    ├── CurrentCard
    └── Forecast
        └── ForecastDay

Milestone 1 — Search one city, end-to-end

Wire the search box to the API and render a current-conditions card. Don't worry about favorites or units yet — just prove the data pipeline works for a single hard-coded unit.

Milestone 2 — Loading & error states

Every fetch has three outcomes, not one. Show a spinner or skeleton while loading, a friendly message on failure (bad city name, network down), and the data on success. This is where amateur apps and solid apps diverge.

Milestone 3 — Shared store: favorites & unit

Introduce your store. Move favorites, unit, and activeCity into it. Now clicking a favorite updates the panel, and the unit toggle re-renders everything consistently.

Milestone 4 — Persist to localStorage

Read the store's initial value from localStorage on startup, and write back whenever favorites or unit change. Reload the page — your choices should still be there.

Milestone 5 — Forecast & polish

Add the multi-day forecast, tidy the layout so it's responsive, add icons, and make sure keyboard users can operate the search and favorites.

Worked Example: The Data Layer

The trickiest, most reusable piece is the fetch-and-cache function. Building it once, cleanly, makes every framework's component code trivial. Here it is framework-agnostic — plain modern JavaScript you can import anywhere.

// src/lib/weather.js
const BASE = 'https://api.openweathermap.org/data/2.5';
const KEY = import.meta.env.VITE_WEATHER_KEY;
const cache = new Map();          // 'city:unit' -> { data, fetchedAt }
const MAX_AGE = 10 * 60 * 1000;   // 10 minutes

export async function getWeather(city, unit = 'metric') {
  const key = `${city.toLowerCase()}:${unit}`;
  const cached = cache.get(key);
  if (cached && Date.now() - cached.fetchedAt < MAX_AGE) {
    return cached.data;           // fresh enough — skip the network
  }

  const url = `${BASE}/weather?q=${encodeURIComponent(city)}`
            + `&units=${unit}&appid=${KEY}`;
  const res = await fetch(url);

  if (res.status === 404) throw new Error(`City "${city}" not found.`);
  if (!res.ok) throw new Error(`Weather service error (${res.status}).`);

  const data = await res.json();
  cache.set(key, { data, fetchedAt: Date.now() });
  return data;
}

Now a React component that consumes it stays small — all the messy caching lives elsewhere:

// src/components/WeatherPanel.jsx
import { useState, useEffect } from 'react';
import { getWeather } from '../lib/weather';

export default function WeatherPanel({ city, unit }) {
  const [state, setState] = useState({ status: 'idle', data: null, error: null });

  useEffect(() => {
    if (!city) return;
    let cancelled = false;
    setState({ status: 'loading', data: null, error: null });

    getWeather(city, unit)
      .then((data) => { if (!cancelled) setState({ status: 'success', data, error: null }); })
      .catch((err) => { if (!cancelled) setState({ status: 'error', data: null, error: err.message }); });

    return () => { cancelled = true; };   // ignore stale responses
  }, [city, unit]);

  if (state.status === 'loading') return <p role="status">Loading {city}…</p>;
  if (state.status === 'error')   return <p role="alert">{state.error}</p>;
  if (!state.data)                return <p>Search for a city to begin.</p>;

  const { name, main, weather } = state.data;
  const symbol = unit === 'metric' ? '°C' : '°F';
  return (
    <article className="current-card">
      <h3>{name}</h3>
      <p className="temp">{Math.round(main.temp)}{symbol}</p>
      <p>{weather[0].description} · humidity {main.humidity}%</p>
    </article>
  );
}

And the persistence helper for Milestone 4 — small, and reused for favorites and unit alike:

// src/lib/storage.js
export function load(key, fallback) {
  try {
    const raw = localStorage.getItem(key);
    return raw ? JSON.parse(raw) : fallback;
  } catch {
    return fallback;   // corrupted or unavailable storage — degrade gracefully
  }
}

export function save(key, value) {
  try {
    localStorage.setItem(key, JSON.stringify(value));
  } catch {
    /* storage full or blocked — ignore, app still works in-memory */
  }
}

Build Checklist

Tick these off as you go. If every box is checked, you've hit the core bar for the project.

What Good Looks Like

Passing the checklist means it works. These qualities are what separate a "works on my machine" demo from something you'd be glad to show an interviewer.

Stretch Goals

Finished early, or want to push the state-management muscle harder? Pick one — depth beats breadth.

• Geolocation: on first load, ask permission and default the dashboard to the user's current location.
• Derived state: add a "feels like vs. actual" badge computed from the data rather than stored — practice computed/useMemo.
• Optimistic UI: when adding a favorite, show it immediately and roll back only if something fails.
• Offline-first: register a service worker so the last-viewed cities render even with no network (a callback to the previous lesson).
• Testing: write a couple of unit tests for getWeather's cache and error handling.
• Deploy: ship it to Netlify or Vercel and put the live URL in your README.

Summary & Quiz

📚 Further Reading

• React — Managing State
• Pinia — Vue's official store
• Open-Meteo — free weather API (no key)
• web.dev — PWA checklist (for the offline stretch goal)

🚀 What's Next?

You've now shipped a real stateful frontend. Next module we turn to the server side of security: Authentication Models and Workflows — how apps prove who a user is and keep them signed in safely.