nahidruhan/spread-fast-client

1. What this repo is

- This is the client-side SPA for Spread Fast, a logistics/courier platform.

- It is a React + Vite application deployed as a static frontend, with a separate backend API described in the README but not included in this repo.

2. App bootstrap and runtime boundaries

- src/main.jsx is the entry point and wires together the global app shell.

- The app uses src/index.css plus the Vite build pipeline, and is hosted via Firebase Hosting config (firebase.json, .firebaserc).

- Static content in public/ is served directly by the hosting layer.

3. Authentication and user identity

- Authentication is centralized in src/context/authcontext and src/context/authprovider, with Firebase initialized in src/firebase/firebase.init.js.

- useAuth.jsx exposes the current user/session state to the rest of the app.

- The auth layer is the main boundary between anonymous users and protected parcel/rider/admin functionality.

4. Routing and access control

- src/routes/Router.jsx defines the client navigation map.

- Route guards are split by role:

- PrivateRoute.jsx for logged-in users

- AdminRoute.jsx for admin-only screens

- RiderRoute.jsx for rider-only screens

- Forbidden.jsx and components/error/* handle access-denied and error states.

5. Layout hierarchy

- The app is organized around three top-level shells:

- RootLayout.jsx for the public-facing site

- AuthLayout.jsx for login/register screens

- DashboardLayout.jsx for authenticated dashboard pages

- Shared chrome lives in src/pages/shared and src/components, especially Navbar, Sidebar, Footer, Logo, Loading, and Border.

6. Public/customer experience

- The home/marketing side is under src/pages/home, with sections for banner, services, how-it-works, features, FAQ, collaboration, and reviews.

- Informational pages like AboutUs and Coverage support the customer discovery flow.

- SendParcel.jsx is the key customer transaction entry point for booking a parcel.

7. Parcel lifecycle and customer dashboard flows

- Customer parcel management is in src/pages/dashboard/my-parcels, including MyParcels.jsx and Tracking.jsx.

- Payment-related screens are isolated in src/pages/dashboard/payment, with explicit success and cancellation return pages.

- PaymentHistory.jsx shows completed transactions and receipt-like history, which implies a backend-backed payment/order record.

8. Rider operations

- Rider-specific UI lives in src/pages/rider and src/pages/dashboard/rider.

- These screens are designed around delivery execution: accepting work, updating delivery status, and managing active jobs.

- The README indicates rider availability/work status is part of the workflow, so the navbar/dashboard likely serves as the control surface for dispatch eligibility.

9. Admin operations

- Administrative parcel oversight is in AllParcels.jsx and PendingParcel.jsx.

- User moderation is handled in UserManage.jsx.

- The admin area is the operational control plane for approving riders, managing users, and moving parcels through hub/origin/destination states.

10. Data access and server interaction

- useAxiosSecure.jsx is the main client-side data access abstraction for authenticated API calls to the backend.

- useRole.jsx likely resolves the current user’s role for routing and UI gating.

- From the README, the frontend talks to a separate Node/Express + MongoDB backend and uses Stripe for payments; Firebase Auth tokens are used to secure requests.

11. Static data and local content

- The app includes local JSON datasets such as public/reviews.json, public/serviceCenters.json, and src/assets/warehouses.json.

- These files support location/coverage and testimonial content without requiring runtime API calls.

- Visual assets are organized under src/assets, including banners and brand imagery.

12. Error, loading, and empty-state handling

- Loading.jsx provides a shared loading state across async screens.

- Error boundaries/pages are split into reusable error and forbidden views, which keeps route failures and authorization failures distinct.

- This suggests the app is designed to handle protected async dashboards gracefully rather than only static marketing pages.

13. Architecture summary for diagramming

- A good diagram would show:

- Public SPA shell → marketing pages

- Auth layer → Firebase login/register/social auth

- Role-gated dashboard → customer, rider, admin sub-flows

- Secure API boundary → useAxiosSecure to backend services

- Payment boundary → Stripe checkout with success/cancel redirects

- Static assets/data → hosted JSON and media files consumed directly by the client