Ghumakkad — Travel Planner
14-screen React travel planner with 4 external API integrations, Chart.js budget dashboards, Leaflet maps, and a full Vitest + MSW test suite.
Architecture flow
Problem
Travel planning is scattered across tabs — weather in one browser tab, budget in another, itinerary in a notes app. Ghumakkad brings itinerary, packing lists, budget tracking, weather, and destination discovery into one responsive planner.
Solution
Built a modular, API-first React frontend with 14 routed screens, 4 normalized API integrations, Chart.js budget visualization, and Leaflet interactive maps — all thoroughly tested with Vitest + MSW.
Architecture
Frontend: React + Vite + React Router + Chart.js + Leaflet
Backend: Client-side only — 4 external APIs via Axios
Infra: Netlify (static deploy)
Key Features
- 14 routed screens across 9 modules: itinerary, packing, budget, weather, destinations
- 4 API integrations: OpenWeather, Nominatim, OpenTripMap, Wikipedia
- Chart.js interactive budget dashboards from user inputs
- Leaflet maps for destination browsing + location discovery
- Vitest + Testing Library + MSW test suite with Husky pre-commit
API Integrations
Four external APIs were integrated, each with inconsistent response shapes requiring normalization:
- OpenWeather API — real-time and forecast weather data for any destination, normalized to a consistent shape for rendering across weather and itinerary screens.
- Nominatim (OpenStreetMap) — geocoding and place search, used for destination lookup and map center coordinates.
- OpenTripMap API — points of interest and attraction data for destination discovery and itinerary suggestions.
- Wikipedia API — destination summary text for context cards on the destination detail screens.
All four APIs were called via shared Axios interceptors with unified loading and error state handling reused across every route — one pattern for all four data sources.
Challenges & Decisions
Integrating four external APIs with inconsistent response shapes and error states. Solved by normalizing all responses through shared Axios interceptors and building consistent loading/error UI components reused across all routes.
A secondary challenge was keeping the budget dashboard reactive without a backend — user inputs drive Chart.js in real time via local state, with no network round-trip. This required careful memoization to prevent unnecessary re-renders as the budget data grew.
Smooth page transitions across 14 routes were achieved using GSAP and Lottie animations applied at the route level — keeping every navigation feel deliberate rather than abrupt.
Testing Strategy
Testing was enforced from the start, not added at the end:
- Vitest + Testing Library — unit and integration tests for components and hooks, with a focus on API response rendering and error states.
- MSW (Mock Service Worker) — intercepted all four external API calls in tests so no real network requests were made, making the suite fast and deterministic.
- ESLint + Prettier — enforced via Husky pre-commit hooks so no malformatted or lint-failing code could be committed.
Design Note
Emphasized whitespace, card-based layouts, and clear hierarchy so dense travel data (budgets, itineraries, weather) remains scannable on any screen size.
Impact
- 14 routed screens across 9 feature modules shipped with consistent UX.
- 4 external APIs fully integrated with normalized error handling and loading states.
- Full Vitest + Testing Library + MSW test suite with ESLint, Prettier, and Husky enforced.
- Chart.js budget dashboards with interactive cost breakdowns from real user inputs.
- Leaflet maps + motion libraries delivering smooth navigation and engagement.
What I'd Improve Next
Add user accounts (auth + persistent trips), search/filter across destinations, and integrate booking APIs.