Weather Dashboard App

One of the most common mistakes in weather dashboard projects is sending a request every time the user submits the form, even when the input is empty or contains only spaces. This wastes API calls, creates confusing error messages, and can quickly become a problem when using a weather API with request limits.

Problematic approach:

          form.addEventListener('submit', async (event) => {
            event.preventDefault();

            const city = cityInput.value;
            const weather = await getWeather(city);

            renderWeather(weather);
          });

This code sends a request even if cityInput.value is empty, contains accidental spaces, or has not changed from the previous search.

Better approach:

          form.addEventListener('submit', async (event) => {
            event.preventDefault();

            const city = cityInput.value.trim();

            if (!city) {
              showError('Please enter a city name before searching.');
              return;
            }

            clearError();
            await searchWeather(city);
          });

Pay attention to: Always trim and validate user input before calling the API. A weather dashboard should not rely on the API to handle every avoidable user mistake. Good validation improves user experience and protects your request quota.

Beginners often assume that fetch() will throw an error whenever something goes wrong. In reality, fetch() only rejects for network-level failures. If the API returns 404 for a city not found or 401 for an invalid API key, the request may still resolve, but response.ok will be false.

Problematic code:

          async function getWeather(city) {
            const response = await fetch(apiUrl + city);
            const data = await response.json();

            return data;
          }

This can pass an error response into your rendering function, causing broken cards, missing values, or confusing text like undefined in the UI.

Recommended solution:

          async function getWeather(city) {
            const response = await fetch(buildWeatherUrl(city));
            const data = await response.json();

            if (!response.ok) {
              throw new Error(data.message || 'Weather data could not be loaded.');
            }

            return data;
          }

Usage with clear error handling:

          async function searchWeather(city) {
            try {
              showLoading();
              const data = await getWeather(city);
              renderWeather(normalizeWeatherData(data));
              saveRecentSearch(city);
            } catch (error) {
              showError(error.message);
            } finally {
              hideLoading();
            }
          }

Pay attention to: Always check response.ok. Your app should have different UI states for loading, success, empty result, city not found, invalid API key, and network failure.

Weather APIs often return deeply nested objects. If your UI reads those fields directly everywhere, the code becomes fragile. One missing field can break the whole dashboard, and switching API providers later becomes much harder.

Fragile rendering:

          temperature.textContent = data.main.temp + '°C';
          humidity.textContent = data.main.humidity + '%';
          wind.textContent = data.wind.speed + ' m/s';
          description.textContent = data.weather[0].description;

This works only when every nested field exists exactly as expected.

Better normalized model:

          function normalizeCurrentWeather(data) {
            return {
              city: data.name,
              temperature: Math.round(data.main?.temp),
              feelsLike: Math.round(data.main?.feels_like),
              humidity: data.main?.humidity,
              windSpeed: data.wind?.speed,
              description: data.weather?.[0]?.description || 'No description available',
              icon: data.weather?.[0]?.icon
            };
          }

Then render from your own model:

          function renderCurrentWeather(weather) {
            cityName.textContent = weather.city;
            temperature.textContent = `${weather.temperature}°`;
            feelsLike.textContent = `Feels like ${weather.feelsLike}°`;
            humidity.textContent = `${weather.humidity}%`;
            wind.textContent = `${weather.windSpeed} m/s`;
            description.textContent = weather.description;
          }

Pay attention to: Create a clean internal data model before rendering. Your components should not need to understand every detail of the external API response. This makes the dashboard easier to debug, extend, and refactor.

Recent search history should represent successful searches. If you save the city name before the API confirms it, your history can fill up with misspelled cities, failed requests, empty strings, or duplicate entries. This makes the feature less useful.

Problematic approach:

          async function searchWeather(city) {
            saveRecentSearch(city);

            const data = await getWeather(city);
            renderWeather(data);
          }

If the request fails, the bad city is already saved.

Better approach:

          async function searchWeather(city) {
            try {
              showLoading();

              const data = await getWeather(city);
              const weather = normalizeCurrentWeather(data);

              renderCurrentWeather(weather);
              saveRecentSearch(weather.city);
            } catch (error) {
              showError(error.message);
            } finally {
              hideLoading();
            }
          }

Deduplicate and limit history:

          function saveRecentSearch(city) {
            const normalizedCity = city.trim();
            const searches = loadRecentSearches();

            const updatedSearches = [
              normalizedCity,
              ...searches.filter((item) => item.toLowerCase() !== normalizedCity.toLowerCase())
            ].slice(0, 6);

            localStorage.setItem('weatherRecentSearches', JSON.stringify(updatedSearches));
            renderRecentSearches(updatedSearches);
          }

Pay attention to: Save searches only after successful responses. Use the city name returned by the API when possible, because it is usually better formatted than raw user input.

Many beginner weather projects use API keys directly inside JavaScript files. For learning projects, this is common, but it is important to understand the limitation: anything shipped to the browser can be seen by users. You should never place private production secrets in frontend code.

Common beginner setup:

          const API_KEY = 'your_real_api_key_here';

          const url = `https://api.openweathermap.org/data/2.5/weather?q=${city}&appid=${API_KEY}`;

This key is visible in browser DevTools and in your public GitHub repository if committed.

Safer learning-project approach:

          const API_KEY = 'YOUR_API_KEY_HERE';
          // Do not commit a real production key.
          // Use a restricted free-tier key only for practice projects.

Better production-style direction:

          // Frontend
          const response = await fetch(`/api/weather?city=${encodeURIComponent(city)}`);

          // Backend or serverless function
          // Reads the real API key from environment variables
          // and calls the weather provider securely.

Pay attention to: For a static beginner project, use a restricted test key and do not commit sensitive credentials. For a real deployed app, move weather requests through a backend or serverless function so the API key can be stored in environment variables.

If a user searches for several cities quickly, an older request may finish after a newer one. Without protection, the app can display the wrong city because the slower earlier response overwrites the latest search result.

Problematic flow:

          async function searchWeather(city) {
            showLoading();

            const data = await getWeather(city);
            renderWeather(data);

            hideLoading();
          }

If the user searches “London” and then immediately searches “Berlin”, the London response may arrive last and replace the Berlin dashboard.

Better approach with request tracking:

          let latestRequestId = 0;

          async function searchWeather(city) {
            const requestId = ++latestRequestId;

            try {
              showLoading();

              const data = await getWeather(city);

              if (requestId !== latestRequestId) {
                return;
              }

              renderWeather(normalizeCurrentWeather(data));
            } catch (error) {
              if (requestId === latestRequestId) {
                showError(error.message);
              }
            } finally {
              if (requestId === latestRequestId) {
                hideLoading();
              }
            }
          }

Pay attention to: Weather dashboards are search-driven interfaces. Protect the UI from race conditions by tracking the latest request, disabling repeated submits during loading, or using AbortController to cancel previous requests.