rafyhossain/classradar

Purpose and Runtime

This is a client-side React application for a class/school dashboard experience: public landing content, authentication screens, and an authenticated dashboard with class schedule, announcements, and quick actions. It runs as a Vite SPA with React HMR/build tooling; no backend, API client, persistence layer, or external service integration is present in the tree.

Entry/bootstrap points:

• index.html

• src/main.jsx

• src/App.jsx

Application Shell and Routing

src/main.jsx mounts the React application, while src/App.jsx provides the top-level application shell. Route definitions are centralized in:

• src/routes/route.jsx

The router is the primary control boundary: it maps public/authenticated-facing page routes to page components and handles the unmatched route through:

• src/pages/NotFound.jsx

No server-side routing or authentication enforcement boundary is evident; auth pages are currently presentation-level routes.

Layout Segmentation

Layouts separate route families and own persistent page chrome:

• src/layouts/MainLayout.jsx

• src/layouts/AuthLayout.jsx

• src/layouts/DashboardLayout.jsx

MainLayout supports the public landing experience, AuthLayout frames login/register pages, and DashboardLayout establishes the dashboard navigation structure. Shared navigation and footer primitives live under:

• src/components/common/Navbar.jsx

• src/components/common/BottomNavbar.jsx

• src/components/common/Footer.jsx

This is the main composition boundary between route content and reusable application chrome.

Public and Authentication Experiences

The public entry experience is composed from focused landing sections:

• src/pages/Landing/LandingPage.jsx

• src/pages/Landing/sections/HeroSection.jsx

• src/pages/Landing/sections/FeaturesSection.jsx

Authentication is represented by distinct login and registration screens:

• src/pages/Auth/Login.jsx

• src/pages/Auth/Register.jsx

These pages do not have corresponding state management, API, token, or identity-provider modules in the repository, so they should be treated as UI flows until backend integration is added.

Dashboard Feature Composition

Dashboard routes provide the core product UI:

• src/pages/Dashboard/DashboardHome.jsx

• src/pages/Dashboard/Schedule.jsx

DashboardHome is assembled from domain-oriented cards for summary information, upcoming classes, announcements, and actions:

• src/components/dashboard/SummaryCard.jsx

• src/components/dashboard/UpcomingClassCard.jsx

• src/components/dashboard/RecentAnnouncements.jsx

The dashboard’s component layer is largely presentational and receives or embeds display data rather than querying a data source.

Schedule Data and Derived Status

The schedule feature has a local data boundary:

• src/constants/weeklySchedule.js

• src/pages/Dashboard/Schedule.jsx

Schedule rendering derives user-facing class state and time display through:

• src/utils/getClassStatus.js

• src/utils/formatTime.js

Thus, the current primary data flow is static schedule data → schedule page/card rendering → derived status/time labels. Replacing weeklySchedule.js with API-backed data is the natural integration point, while preserving these derivation utilities as view-model logic.

UI System and Styling

Reusable UI primitives form a lightweight design-system boundary:

• src/components/ui/button.jsx

• src/components/ui/navigation-menu.jsx

• src/components/ui/sheet.jsx

Shared layout primitives are in src/components/ui/Container.jsx and src/components/ui/Section.jsx. Global and app-level styling is handled by:

• src/index.css

• src/App.css

Utility class composition is centralized in src/lib/utils.js, supporting consistent styling behavior across component layers.