irfan-chowdhury/ph-level2-b5-assignment-6-frontend

1. Overall shape

This is a single-page frontend built with React + Vite + TypeScript, styled with TailwindCSS and a large set of Radix/shadcn-style UI primitives. The app is organized around role-based experiences for User, Agent, and Admin, with a public marketing/landing area and separate authenticated dashboards.

2. Entry and application shell

The runtime starts in src/main.tsx, which mounts the app and applies global providers. src/App.tsx and src/routes/index.tsx appear to own top-level route composition, while src/index.css provides global styling. The app also wraps theme handling through src/providers/theme.provider.tsx and src/context/theme.context.ts.

3. Routing and access control

Route boundaries are enforced in src/utils/ProtectedRoute.tsx, src/utils/withAuth.tsx, and src/utils/generateRoutes.ts. These utilities gate access by authentication state and role, and likely redirect unauthorized users to src/pages/Unauthorized.tsx. This is the key boundary between public pages and dashboard-only pages.

4. Public-facing pages

The public surface includes Homepage, About, Features, FAQ, Pricing, Contact, Privacy, Terms, Tours, TourDetails, Booking, plus Login, Register, Verify, and payment result pages (Success, Fail). These pages are mostly routed through a common layout and share a landing-page style UX rather than dashboard chrome.

5. Role-based dashboard layouts

There are distinct layout shells for each role in src/components/layout and mirrored dashboard page shells under src/pages/Dashboard/{Admin,Agent,User}. Each role has its own Navbar, Sidebar, and Footer, which means the UI boundary is not just route-based but also layout-based. This is where the authenticated workspace is visually and functionally separated.

6. Core wallet domain flows

The wallet application centers on wallet balance and transaction operations. User pages handle deposit, send money, withdraw money, transaction history, and profile management. Agent pages handle cash-in/cash-out on behalf of users and their own wallet actions. Admin pages manage users, agents, wallets, and transaction oversight. These flows are the main business paths that should dominate any architecture diagram.

7. State management and server communication

The data layer is centered on Redux Toolkit with RTK Query-style APIs in src/redux. Important API slices include auth.api.ts, walletApi.ts, profileApi.ts, adminApi.ts, dashboardApi.ts, booking.api.ts, tour.api.ts, and division.api.ts. Requests are built on a custom Axios base layer in src/redux/axiosBaseQuery.ts and src/lib/axios.ts, with a shared store in src/redux/store.ts.

8. Backend boundary

The frontend talks to a backend API configured through VITE_BASE_URL in the environment. The README indicates REST endpoints for authentication, wallet actions, transaction history, and admin management. So the architecture boundary is a classic React client → HTTP API backend model, with no local persistence layer beyond client state and auth/session handling.

9. Authentication and role model

Auth is handled through Redux-backed APIs plus service wrappers in src/services/authService.ts, src/services/userService.ts, and src/services/walleteService.ts. Role constants live in src/constants/role.ts, and login/logout behavior is supported by hooks like useLogout. The key architectural concern is role-aware session state that drives both routing and menu visibility.

10. Reusable UI and form infrastructure

Shared interaction pieces live under src/components/ui and include dialogs, tables, forms, inputs, selects, sheets, tooltips, and alerts. Higher-level reusable components such as ProfileForm, SingleImageUploader, MultipleImageUploader, and confirmation dialogs support multiple features across pages. This keeps feature pages thin and pushes interaction patterns into reusable modules.

11. Theme and device responsiveness

The app supports dark/light mode via ModeToggler, useTheme, and the theme provider/context pair. Responsive behavior is also supported through use-mobile and mobile-oriented layout components. These are cross-cutting concerns rather than feature-specific code, so they sit beside routing and auth in the architecture.

12. Feature modules and legacy/secondary domain code

There is a secondary feature set around tour/division/admin content management under src/components/modules/Admin, src/components/modules/Tours, and related pages like AddTour, AddDivision, and AddTourType. This looks like either a shared template layer or legacy domain code coexisting with the wallet product. For diagramming, treat it as a separate feature area adjacent to the wallet core, not the main business spine.

13. Deployment/runtime tooling

The project is configured for Vite-based frontend builds, with deployment files such as vercel.json and deploy.yml. The app is therefore a static frontend artifact that depends on an external API service at runtime, rather than a server-rendered or monolithic backend app.

14. Important diagram takeaway

The clearest architecture view is: public marketing/auth pages → authenticated role-based dashboards → Redux/RTK Query + Axios data layer → remote wallet/admin API. Around that core are shared UI primitives, theme/responsiveness concerns, and a smaller set of legacy tour-management modules.