Weather Forecast App - SvelteKit with dynamic search and unit conversi

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

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

What I'm most proud of

I'm most proud of successfully implementing complex application logic for the first time. Coming from a background of building static landing pages, this project challenged me to think about data flow, state management, and API integration.

The dynamic city search with debouncing and the unit conversion system that updates everything reactively were particularly satisfying to build. I'm also proud that I maintained clean code organization throughout - separating concerns into utils, components, and state management made the growing complexity manageable.

What I would do differently next time

Better upfront planning: I would plan the architecture more thoroughly before starting. I initially underestimated how features would interact with each other. For example, the unit conversion system required refactoring my mappers when I realized the UnitsButton component lived in the layout, not the page, making global state necessary.

Test-driven development: I'd implement the project with testing in mind from the start. I didn't write any tests, which made me nervous when adding new features - worried I might break existing functionality.

Research framework constraints early: I attempted to add automatic geolocation but struggled with SvelteKit's SSR/CSR boundaries. Next time, I'd research these framework-specific constraints earlier rather than discovering them mid-implementation.

Despite these learning points, the project was incredibly valuable for my growth as a developer.

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

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

Challenge 1: Managing Growing Complexity

The Problem: As I added features (search autocomplete, day filtering, unit conversion), the codebase grew more complex. I worried about maintaining it and feared adding bugs.

Solution: I learned to separate concerns properly. I created dedicated utility files (api.ts, converters.ts, mappers.ts) instead of putting everything in components. This made the code much more manageable and easier to understand.

Challenge 2: Debouncing Search Input

The Problem: Every keystroke triggered an API call, which was inefficient and could hit rate limits.

Solution: I implemented a debounce pattern using setTimeout. The app waits 300ms after the user stops typing before making the API call. This reduced API calls by approximately 70%.

searchTimeout = setTimeout(async () => {
    const results = await searchCities(query);
    citySuggestions = results;
    isLoadingSuggestions = false;
}, 300);

Challenge 3: Component Communication Across Layout Boundaries

The Problem: The UnitsButton component lives in the header (inside +layout.svelte), but the weather data displays in +page.svelte. Props and callbacks wouldn't work across this boundary.

Solution: I used a global state module with Svelte 5's $state rune. Any component can import and modify the unit system, and all reactive derivations update automatically.

Challenge 4: Filtering Hourly Data by Day

The Problem: The API returns all hourly data in a single array. I needed to filter it by the selected day while maintaining the correct temperature and weather code indices.

Solution: Instead of slicing the array, I iterated through all dates, stored the indices that matched the selected day, then used those indices to map the correct data:

hourly.time.forEach((date, index) => {
    const dayOfWeek = date.toLocaleDateString('en-US', {weekday: 'long'});
    if (dayOfWeek === selectedDay) {
        filteredIndex.push(index);
    }
});

Challenge 5: SSR vs CSR with Geolocation

The Problem: I attempted automatic geolocation in +page.ts, but navigator.geolocation doesn't exist on the server.

Solution: I didn't fully solve this one. I learned that some browser APIs only work client-side, and understanding SvelteKit's SSR/CSR boundaries is crucial. This is something I'll research more deeply for future projects.

---

Each challenge taught me something valuable about building real applications versus static pages. The key was breaking problems down, researching solutions, and not being afraid to refactor when needed.

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

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

I'd appreciate feedback on:

Code Architecture

• Is my separation of concerns (API, mappers, components, state) appropriate, or could it be better organized?
• Are there any code smells or anti-patterns I should be aware of?

User Experience

• Does the app feel intuitive to use, or are there confusing elements?
• Are the loading states clear enough?
• Is the error handling adequate when searches fail?

Performance

• Are there any obvious performance bottlenecks?
• Could the API calls be optimized further?

Accessibility

• I haven't thoroughly tested keyboard navigation and screen reader support
• Are there accessibility issues I should address?

Edge Cases

• Try unusual city names, very long names, or special characters
• Switch rapidly between units and days - does everything update correctly?
• Test on different screen sizes and browsers

I'm particularly interested in honest feedback about maintainability since this is my first complex application. If you see areas where the code could be cleaner or better structured, I'd love to know - even if it means significant refactoring.