This repository contains the frontend repository for the LMS project, and the actual React application lives inside the lms-frontend/ subdirectory.1 In its current state, the frontend is a React 18 dashboard application built with Create React App, Material UI, MUI Data Grid, React Router, FullCalendar, and several charting libraries for a role-aware learning management interface.2 3
The repository structure matters because the root README and root files are minimal, while the real application code and configuration are nested inside lms-frontend/.1 2 This README therefore documents the repository as it exists now, not the default Create React App boilerplate that still appears in the nested application README.4
The real frontend app is not at the repository root. Anyone cloning this repository needs to enter lms-frontend/ before running the application, installing dependencies, or building it.1 2
| Path | Purpose |
|---|---|
lms-frontend/ |
Actual React application |
lms-frontend/src/App.js |
Main route shell and auth-gated layout |
lms-frontend/src/components/ |
Dashboard pages, auth screens, CRUD UIs, and shared UI |
lms-frontend/src/scenes/ |
Chart and calendar scenes |
lms-frontend/src/theme.js |
Color mode and theme tokens |
lms-frontend/public/ |
Static frontend assets |
The frontend is a role-aware LMS dashboard rather than a public marketing site. It centers on login-gated access, dashboard metrics, user management, room management, class-section mapping, attendance recording, attendance viewing, and calendar/chart widgets.3 5 6 7
The application reads authentication state from localStorage and conditionally shows the sidebar, topbar, and protected routes only when loggedIn is set to true.3 After login, the stored role value determines whether the user is treated as an admin or as a teacher in navigation and screen behavior.3 6
| Area | What is currently implemented | Main sources |
|---|---|---|
| Authentication | Login page, guarded routes, token and role persistence in localStorage |
3 8 |
| Dashboard | KPI cards, calendar widget, and satisfaction chart | 5 |
| User management | Separate screens for admins, teachers, students, and user creation | 3 6 9 |
| Academic structure | Classes, sections, and class-section mapping screens | 3 10 |
| Attendance | Attendance recording and attendance management screens | 3 7 11 |
| Navigation | Sidebar with role-based menu visibility | 6 |
The login screen posts credentials to the deployed backend API at https://lms-backend-codi-production.up.railway.app/api/login and stores the returned token, loggedIn flag, and role in localStorage.8 From that point onward, the app uses those stored values to decide which screens to render and what authorization headers to send with subsequent requests.3 5 7
This means the current frontend is tightly coupled to a deployed Railway backend URL, not a configurable environment-based API client.8 11 That is an important repository characteristic, because running the frontend locally without refactoring still points it to the hosted backend instead of to a local server.
| Stored value | Current use |
|---|---|
token |
Sent as Bearer token in API calls |
loggedIn |
Determines whether protected layout elements render |
role |
Controls admin-versus-teacher navigation and behavior |
The route shell in src/App.js shows that almost the entire application is access-gated. When the user is not logged in, most routes resolve back to the login screen. Once authenticated, the app renders the dashboard shell and exposes the rest of the LMS screens.3
| Route | Current screen |
|---|---|
/login |
Login screen when logged out; Home when logged in |
/register |
Register screen when logged in; Login when logged out |
/ |
Dashboard home when logged in; Login when logged out |
/createuser |
Create user form |
/RecordAttendance |
Record student attendance form |
/admin |
Admin users screen |
/teacher |
Teachers screen |
/students |
Students screen |
/classes |
Classes management screen |
/sections |
Sections management screen |
/class-section |
Class-section management screen |
/StudentAttendance |
Attendance management screen |
/calendar |
Calendar view |
/* |
404 page |
The sidebar provides one of the clearest views of the actual information architecture. All authenticated users can reach the dashboard, create-user form, attendance recording, students, classes, sections, class-section management, calendar, and attendance listing.6 When the stored role is admin (role === "1"), the sidebar additionally exposes Register, Admins, and Teachers pages.6
This means the current interface distinguishes between admin and teacher modes primarily through frontend navigation and backend permissions, while students do not appear to have a dedicated dashboard route of their own in this repository.3 6
| Sidebar group | Current items |
|---|---|
| Users | Create a User, Add Student Attendance, Register (admin only), Admins (admin only), Teachers (admin only), Students |
| Rooms | Classes, Sections, Class Section |
| Others | Calendar, Student Attendance |
The dashboard home screen fetches users, classes, and sections from the backend and renders summary cards for teachers, students, classes, and sections.5 In admin mode, all four counts are shown; in teacher mode, the view is simplified to students, classes, and sections.5 The page also includes a FullCalendar widget and a satisfaction bar chart, which gives the application more of an administrative dashboard feel than a simple CRUD panel.5
The academic-management screens are built around Material UI and DataGrid-style workflows. The class-section screen, for example, loads class, section, and joined mapping data, supports creation of new mappings, and allows update and delete actions through authenticated API calls.10 Similar patterns appear across classes, sections, and user-management pages.
Attendance is handled in two distinct screens. The Record Attendance screen is a form-driven workflow that lets staff choose a student, supply teacher and class-section identifiers, and submit a status of Present, Late, or Absent.7 The Student Attendance screen is a table-oriented management view that loads previously recorded attendance data and supports edits and deletions.11
| Feature | Current behavior |
|---|---|
| Login | Authenticates against the deployed backend and persists token/role in local storage |
| Dashboard | Displays role-aware totals, a calendar, and chart widgets |
| User creation | Allows role-controlled creation of staff or student accounts depending on current user role |
| Classes and sections | CRUD-style management screens backed by authenticated API calls |
| Class-section mapping | Links classes to sections and supports add, edit, and delete operations |
| Attendance recording | Creates attendance with student ID, teacher ID, class-section ID, and status |
| Attendance management | Loads and manages existing attendance entries |
The current frontend is directly coupled to a deployed backend at https://lms-backend-codi-production.up.railway.app rather than to a local environment variable-based API client.5 7 8 10 11 Most key features send authenticated requests to /api/... endpoints on that backend, using the token stored in localStorage as a Bearer token.
| Frontend feature | Backend endpoint pattern |
|---|---|
| Login | /api/login |
| Logout | /api/logout |
| Register | /api/register |
| Users | /api/users |
| Classes | /api/classes |
| Sections | /api/sections |
| Class sections / joins | /api/classsections, /api/join |
| Attendance | /api/attendances |
Because those URLs are hard-coded in the components, local frontend development currently depends on the hosted backend unless the code is manually refactored to use a configurable API base URL.5 7 8 10 11
The dependency set shows a modern dashboard-oriented React stack built around Material UI, FullCalendar, chart libraries, and Create React App.2 The result is a visually structured admin interface rather than a minimal form-based application.
| Category | Current stack |
|---|---|
| Core | React 18, React DOM, Create React App |
| Routing | React Router v6 |
| UI system | Material UI, Emotion, MUI Icons, MUI Data Grid |
| Charts | Nivo, Chart.js, react-chartjs-2 |
| Calendar | FullCalendar |
| State/helpers | Formik, Yup, React Toastify |
| Layout | react-pro-sidebar |
| Data access | Axios and Fetch |
Since the real application is nested, local work should start in lms-frontend/ rather than at the repository root.1 The package configuration uses Create React App scripts, but the development server is explicitly configured to run on port 5000.2
| Step | Command |
|---|---|
| Enter the frontend app | cd lms-frontend |
| Install dependencies | npm install |
| Start development server | npm start |
| Create production build | npm run build |
| Run tests | npm test |
One practical caution is that the frontend's npm start script uses PORT=5000 react-scripts start, so its default local port collides with many backend defaults. In addition, the API calls still target the deployed Railway backend rather than a local one.2 8
This README is intentionally aligned with the repository as it exists now, including implementation details that future contributors may want to refine later.
| Topic | Current state |
|---|---|
| App location | The actual React app is inside lms-frontend/, not at repository root. |
| Documentation state | The root README was minimal, while the nested lms-frontend/README.md remains default CRA boilerplate. |
| Auth persistence | Session state is stored in localStorage, not in cookies or a dedicated auth store. |
| API coupling | Backend URLs are hard-coded to the Railway deployment across many components. |
| Route gating | Most routes fall back to Login when the user is not marked as logged in. |
| Role-aware navigation | Admin-only navigation items are controlled client-side by localStorage.role. |
| Local port choice | The CRA dev server is configured to run on port 5000, which can conflict with local backends. |