supratim-2006/traffic-website

1. Overall shape

This is a TanStack Start application: a React 19 UI with SSR via Nitro, built and served as a full-stack web app rather than a purely client-side SPA. The main user experience is a traffic operations dashboard for incident management.

2. Request and render entry points

The app boots through src/start.ts and src/server.ts, which define the client/server execution boundary. src/router.tsx plus the generated src/routeTree.gen.ts wire up the TanStack Router tree, while src/routes/__root.tsx provides the shared layout shell and src/routes/index.tsx is the primary dashboard route.

3. Primary domain surface

The core product area lives under src/components/dashboard/. These components form the command-center workflow: incident intake, location selection, live detection, congestion analysis, map-based diversion routing, dispatch recommendations, and results summaries. The dashboard is decomposed into many focused panels rather than one monolith.

4. Data flow through the dashboard

A typical flow is: incident input / location selection → analysis modules (emergency detection, congestion scoring, predictions, detected objects, heatmap) → recommendations and dispatch → route diversion visualization. Components like IncidentInput, LocationPicker, CongestionAnalysis, Predictions, Recommendations, DispatchPanel, and RoutingDiversions suggest the UI is organized around this operational pipeline.

5. Map and geospatial layer

Geospatial rendering is a major subsystem. TrafficHeatmap, DiversionRouteMap, and RoutingDiversions indicate the app uses Leaflet and Leaflet.heat to show incident locations, congestion intensity, and alternative routes. The custom type declaration in src/types/leaflet-heat.d.ts exists to support the heatmap integration cleanly in TypeScript.

6. API and integration boundary

src/lib/traffic-api.ts is the likely integration layer for traffic-related data and analysis. The README also calls out TanStack Query, so the app probably treats external or server-backed traffic data as queryable resources rather than embedding fetch logic in UI components. This keeps network concerns separated from presentation.

7. Shared UI system

src/components/ui/ contains the reusable design-system primitives, likely generated from shadcn/ui and built on Radix UI. These are the low-level building blocks used across the dashboard for dialogs, tabs, sheets, tables, buttons, inputs, etc., while the dashboard-specific components compose those primitives into operational screens.

8. Layout, navigation, and responsiveness

DashboardLayout, TopBar, WorkflowSidebar, TabContent, and SectionHeader define the app shell and navigation hierarchy. src/hooks/use-mobile.tsx suggests responsive behavior is centralized so the dashboard can adapt between desktop control-room layouts and smaller screens.

9. Error handling and resilience

src/lib/error-capture.ts, src/lib/error-page.ts, and src/lib/lovable-error-reporting.ts indicate explicit error boundary/reporting support. This matters because the app likely depends on live data and map rendering, both of which need graceful failure states.

10. Styling and global assets

Global styling is driven by src/styles.css with Tailwind CSS v4. Static assets live in public/, and the components.json configuration confirms the shadcn/ui pipeline. The repo is optimized for a design-system-driven UI rather than custom CSS per component.

11. Type and build-time boundaries

src/types/ holds shared TypeScript definitions, while src/routeTree.gen.ts is generated and should be treated as build output, not source of truth. The build setup (vite.config.ts, bunfig.toml, package.json) is oriented around Bun for install/run and Vite/TanStack Start for bundling.

12. Deployment model

The README states deployment targets Vercel using the TanStack Start preset. In architecture terms, that means the app is shipped as an SSR-capable web service with static asset delivery and server-side rendering managed by the framework/runtime, not a separate backend repository.