weather-app-frontendmentor

What are you most proud of, and what would you do differently next time?

I’m proud of shipping a weather app that feels fast and intentional: debounced search with request cancellation, normalized data adapters for daily/hourly views, clear empty/error states, and a responsive layout that holds up from mobile to desktop. I also like the units dropdown that updates the UI immediately and keeps the interface predictable.

Next time I would:

• Persist the last city + unit preferences to storage so the app reopens with the same context.
• Move all network calls behind a Next.js route handler with caching (revalidate) to control latency and avoid CORS quirks.
• Add runtime validation (e.g., Zod) for API responses to catch shape changes early.
• Invest in a11y from day one (combobox semantics for search, focus management, full keyboard flows).
• Add component tests for adapters and store actions, plus a couple of e2e flows (search → select → view forecasts).

What challenges did you encounter, and how did you overcome them?

• Stale requests & race conditions: Rapid typing triggered overlapping calls. I combined a debounce with AbortController and a simple requestId guard so only the freshest response wins.
• Timezone/locale formatting: The API returns times in a specific TZ. I standardized formatting with Intl.DateTimeFormat and passed the API timezone through adapters so labels like “Hoy” and 12-hour times render correctly.
• Mapping WMO codes to icons/states: I built a utility to translate weather codes (e.g., 45/48 fog) to consistent icons and labels, with sensible fallbacks.
• Separating UI from data shape: The raw API is array-heavy. I introduced adapter helpers that zip arrays into presentation-ready objects, keeping components dumb and testable.
• Empty vs. error: I treated “0 city results” as a friendly empty state and reserved error UIs for true network failures—this kept the UI calm under poor connectivity.
• Layout stability: Skeletons, fixed heights, and avoiding cross-axis items-center (which shrinks sections) prevented layout jumps while loading.

What specific areas of your project would you like help with?

• Architecture: Is my “feature-first + adapters + Zustand actions” structure solid, or should I lean more on RSC/Suspense and server data fetching?
• Units strategy: For switching °C/°F, km/h↔mph, mm↔in—would you keep client-side conversion for instant feedback, or refetch from the API for canonical units? Trade-offs in real projects?
• Accessibility: Review the search as a proper combobox (ARIA, keyboard navigation, focus), and the units popover (menu/menuitemradio semantics).
• Performance: Ideas for memoization/virtualizing the hourly list, smarter caching (SWR, stale-while-revalidate), or splitting icon/SVG assets to trim bundle size.