mahmudswe/airawarehub_frontend

1. This is a single-page React application built with Vite. The runtime entry points are src/main.jsx and src/App.jsx, with routing centralized in src/routes/routes.jsx. There is no backend code in the repo, so the app appears to consume external APIs through its service layer.

2. The top-level architectural split is by responsibility:

- src/pages contains route-level screens.

- src/components contains reusable UI and feature widgets.

- src/services contains API-facing logic.

- src/utils contains cross-cutting helpers like axios setup, endpoint constants, and AQI color mapping.

- src/styles and CSS files handle presentation.

3. The main user-facing flows seem centered on air-quality and city exploration. The page names suggest major screens for home, search, map viewing, city comparison, and socio-economic factors. ErrorPage.jsx is likely the route fallback or failure screen.

4. The map subsystem is isolated under src/components/Map with MapWithRoutes.jsx, and a corresponding src/pages/MapView.jsx. This indicates the map is a dedicated feature boundary rather than just a small widget. src/services/map.service.js likely supplies data for routes, locations, or map overlays.

5. The AQI subsystem is also clearly separated under src/components/aqi. AqiCircularProgress.jsx, AqiHorizontalBar.jsx, and AirQualityDetails.jsx suggest multiple visualizations for the same air-quality data. src/utils/aqiColors.util.js likely standardizes AQI-to-color rendering across the app.

6. Shared UI components in src/components/shared support cross-page reuse:

- Search.jsx for querying cities or locations.

- CurrentLocation.jsx for geolocation-driven context.

- CityComparisonTable.jsx for side-by-side metrics.

- ToggleSwitch.jsx for mode or filter toggles.

- Toastify.jsx for user notifications.

These are likely composed inside the page-level screens rather than owning their own routes.

7. Navigation and layout are handled separately from content. src/components/nav contains navbar.jsx, SideNav.jsx, and SideNavToggleButton.jsx, indicating the app uses a persistent nav shell with an expandable side menu. src/components/loader/loadingOverlay.jsx suggests an app-wide loading state overlay used during API requests or route transitions.

8. The service boundary is intentionally thin and centralized. src/services/city.service.js and src/services/map.service.js likely encapsulate request construction and response shaping, while src/utils/axios.util.js provides a configured HTTP client and src/utils/endpoint.util.js stores API endpoint definitions. This keeps network concerns out of React components.

9. Styling is a mix of utility-driven and custom CSS. The presence of tailwind.config.js, postcss.config.js, src/index.css, src/App.css, and src/styles/styles.css indicates Tailwind is part of the styling pipeline, with some app-specific overrides or shared styles layered on top.

10. The app is organized as a data-driven UI that likely follows this flow: route selection -> page component -> service call via axios utility -> data formatting/presentation in shared or feature components -> user feedback via loading overlay/toasts. That separation is important for an architecture diagram because it distinguishes navigation, data access, and visualization.

11. The external dependency surface appears to be limited to HTTP APIs and possibly browser geolocation/maps APIs. No state management library or backend integration layer is visible in the tree, so state is probably handled with React component state and props, with route-local orchestration rather than a global store.

12. For diagramming, the key boundaries to show are: routing shell, page-level screens, reusable UI widgets, feature-specific AQI and map modules, and the service/utils layer that mediates all remote data access. That structure is the main architectural shape of the repository.