shahriar-hossain-alvi/edutrack-frontend

1. Project type and boundary

- This repository is the React frontend for Edutrack, a result management system.

- It does not contain the FastAPI/PostgreSQL backend; instead it consumes backend APIs for auth, user management, marks, courses, logs, and results.

2. Application shell

- The app boots from src/main.jsx, with global styling in src/index.css.

- Root-level concerns are provided by src/provider/AuthProvider.jsx and src/provider/ThemeProvider.jsx, which make authentication state and UI theme available across the tree.

3. Routing structure

- Routing is split by audience and access level:

- src/app/routes/Routes.jsx for the overall route composition

- AdminRoutes.jsx, TeacherRoutes.jsx, StudentRoutes.jsx for role-specific route sets

- Public pages include signin, error, and unauthorized screens.

- Private pages include authenticated views such as results and single-user details.

4. Access control and redirects

- src/components/RouteHandlers/PrivateRoutes.jsx protects authenticated routes.

- RoleBasedRedirects.jsx handles user-type redirection after login or when a role lands on an incompatible route.

- This makes authorization a routing concern in the frontend, mirroring the backend role model.

5. Layout hierarchy

- The UI uses separate shell layouts for different audiences:

- MainLayout.jsx

- AdminLayout.jsx

- TeacherLayout.jsx

- StudentLayout.jsx

- These layouts likely define shared chrome such as navigation, sidebars, and page framing, while the inner route content changes by role.

6. Authentication and API access

- src/hooks/useAuth.jsx exposes auth state and likely user profile/session details.

- src/utils/axios/axiosPublic.js and axiosSecure.js define two API clients:

- public requests for unauthenticated endpoints

- secure requests for authenticated endpoints

- useAxiosInterceptor.jsx is a key cross-cutting hook; it aligns frontend requests with the backend’s cookie-based JWT setup described in the README.

7. Feature areas by role

- Admin pages dominate the app:

- dashboard, users, departments/semesters, subjects, assigned courses, marks, audit logs, user creation

- Teacher pages focus on assigned courses and profile

- Student pages focus on offered courses, marks, and profile

- This suggests the frontend is organized around a role-based CRUD and read-only workflow model rather than a single generic dashboard.

8. Page composition pattern

- src/pages/* contains route-level screens.

- src/components/pageComponents/* contains the transactional or form-heavy UI used inside those pages.

- Examples:

- user creation tabs for students/teachers

- department and semester forms/tables

- mark insertion and mark update flows

- subject creation and course assignment flows

- This split keeps routing/page concerns separate from reusable domain UI.

9. Shared UI building blocks

- src/components/ui contains reusable presentation pieces:

- navbar, drawer sidebar, loading spinner, skeletons, charts, dashboard cards, recent audit logs, generic user forms

- These are used across multiple pages and layouts, acting as the frontend’s design system layer.

10. Hooks and client behavior

- useDebounce.jsx indicates request-throttled interactions, likely for search or filter inputs.

- useTheme.jsx centralizes theme switching.

- useAxiosSecure.jsx and useAxiosPublic.jsx encapsulate API client selection, keeping pages free from request plumbing.

11. Utilities and helpers

- src/utils/errorMessageParser/errorMessageParser.js normalizes backend/API errors into user-facing messages.

- src/utils/SectionHeader/SectionHeader.jsx is a small shared layout utility.

- This layer supports consistent UX around API failures and section presentation.

12. Data flow at a glance

- User signs in through the auth page.

- Auth state is stored in the provider and propagated through the app.

- Protected routes and role-based redirects determine which layout and pages are visible.

- Pages invoke secure/public axios clients to call the backend.

- Backend responses populate tables, dashboards, charts, and forms; errors are parsed into readable messages.

13. Deployment and runtime

- The frontend is built with Vite and deployed separately from the backend.

- Dockerfile and docker-compose.yml support containerized local development/builds.

- vercel.json indicates Vercel deployment support for the frontend.

- public/test_data.json suggests some local/mock data usage for development or UI testing.

14. Architecture summary

- Overall, this is a role-based single-page application with:

- auth/theme providers at the root

- route guards and role redirects

- separate layouts per user type

- page-level screens backed by reusable domain components

- centralized axios clients and hooks for API access

- The main architectural boundary is between this React client and the external FastAPI backend it consumes.